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
i prefer not edit all files .
i will locate file manually . not problem to me .
Thank you .
If you are fixing layout bugs, I wish you would look at this report I submitted in 2020. The problem persists for me in 4.20.0.4
Request #333530
Overridden keyboard shortcuts are lost when reloading a layout that assigned them
I've just tried it, works for me. I created a new keyboard shortcut, instead of overwriting an existing one.
He did indeed.
... However, it is the customer's fault if they fail to make backups. Or alternatively, go to a product that is more customer friendly in their perception.
Personally, I find Daz fairly customer friendly - just not as much as they used to be.
I make backups; because it isn't other folk's responsibility but mine. I know Daz's stance, which is implied if not stated.
This help request specifically addresses problems when overriding one of the built in (or perhaps they are called default) keyboard shortcuts. I have no problem assigning an unused shortcut to a custom action.
To save you the time of looking up the actual help request, this is what it says:
According to the help request, this was reported to the developers (bug tracker) on June 09, 2020 14:53. CS closed the help request and marked it "Solved", like they do for any request that goes to the developers, because (according to CS) the developers never respond to CS with any feedback about whether the bug report has been resolved. Users are expected to just watch the change log to see if anything is ever written there about their issues. This is a terrible system, in my opinion.
Can you select and move the tringles in the timeline once you select them? Or they stay locked in place until you create a key on the "cast shadows" line?
Before you ask, yes, I can move those triangles as soon as they are created in 4.12.0.86. It's a bug that DAZ Studio got since 4.14.
The problem is the aliases; properties can be keyed via aliases but doing so makes unselectable key groups. Specifically click select, drag select and move all work until I do a key on an alias and then I can't click select or move (but I can drag select) the key group without doing a full TRSOAH select. Up to the alias key operation I can do partial selectes, e.g. just "T", and move the translate properties independently of all the others.
Personally I think it is trying to be over-functional; I don't think I ever want to move just some of the properties, I want to move everything, or delete everything with Key-. It's a PITA having left over H properties after a Key-
Another bug: create primitive is not creating an undo entry and can't be undone.
Did everyone get the new beta this morning?
4.20.0.4
Changelog doesn't show much activity.
http://docs.daz3d.com/doku.php/public/software/dazstudio/4/change_log
looks like they are still working on getting the layouts to save correctly.
Layouts and toolbars should save correctly now.
There are log messages now recording the save of the .dsx files:
2022-03-04 10:30:30.040 [INFO] :: Saving Custom Actions: %AppData%/DAZ 3D/Studio4 Public Build/ customactions.dsx
2022-03-04 10:30:30.048 [INFO] :: Saving Actions: %AppData%/DAZ 3D/Studio4 Public Build/ actions.dsx
2022-03-04 10:30:30.071 [INFO] :: Saving Menus: %AppData%/DAZ 3D/Studio4 Public Build/ menus.dsx
2022-03-04 10:30:30.101 [INFO] :: Saving ToolBars: %AppData%/DAZ 3D/Studio4 Public Build/ toolbars.dsx
I asume based on the log details that they will now be created if they don't exist, as before; it looks like only layout.dsx was fixed in .3
EDIT: Corrected the paths above. All the files are now being created; I tested by deleting the Studio4 Public Build directory.
The Roaming folder names is suplied by %AppData%, only the Daz 3d folder on is additional.
Yes, my mistake: %AppData%\Daz 3D, then all the configuration stuff not in the registry (most of it) is in that directory.
Are anyone finding that you cannot dial out morphs?? Added Mousso morphs and Lainey morphs to 8.1 base female as I have done before but now cannot dial them out to the default ?? Anyone else experienced this bug?
or you dial in a character and in all is messed up
I agree with this 134%, but the fact of the matter is that Daz chose to restrict people's access to previous versions of their software, so there needs to be a sticky made, or large post in a new beta/gen release thread letting users know that they cannot revert their changes unless they have made their own backups!
How is that sticky post in the forums going to help users who never install any Public Beta versions and never visit forums, but instead just update their Release version in DAZ Install Manager and then discover that half of their content no longer works as it did?
Proper solution is to not allow users to update in DIM without reading release notes first. That would of course require that there are release notes available to begin with.
Also, it wasn't you who said it, but the thinking that "it's users' fault for not having backup" is unreasonable because backups can fail.
Daz Studio users are not IT administrators who know that the only real backup is if you store your files in at least 3 different places -- locally, online, and offline / off-site and then perform weekly tests to see if you can actually restore from those.
I'm probably grasping at straws here.
Can an LPE be used to make ghost lights behave like they did before the opacity/luminance change?
https://www.migenius.com/doc/realityserver/4.3/resources/general/iray/manual/concept/light_path_expression_grammar.html
Yes. It's some combination of <RS> elements in the path involving something tagged as a ghost light. What it is depends on what the precise definition of a ghost light is; indeed the description would be a precise description of "ghost light behaviour".
Not sure if this has been noted already since I haven't gone through the 27 pages, but on 4.20 with Iray Server 3.44, my render times quadrupled. I sent in a ticket for it but figured I'd post it here too. This is with a small scene with an RTX 3090 on GPU only. Final output was exactly the same, just way slower. (ignore the compatibility message, I took the screenshot after switching versions)
I found a problem in Iray. I expected a complete darkness interior but light keeps getting in.
Light is expected to travel through volumes and transparent objects but not in solid objects.
This might be the root cause that makes some figures to generate lots fireflies.
Is the render using CPU or GPU? What is the driver version?
Render is using the GPU, I verified Cuda cores were at 95+ percent the whole time, and both Daz and IS are set to GPU only. There is a ton of new spam in the Iray Server command line about "sending chunks 1-300" that wasn't there before, but not sure if it's related.
Driver version is 511.65 from Jan, I see there is a new one from Feb, lemme grab that and see if it makes any difference.
After updating the driver to the latest version, running the render again as a new job is matching the slow speed with only 100 iterations done after 10 minutes. So updating the driver didn't seem to make a difference unfortunately.
I can't help but notice that the screenshot for 4.20 says "incompatible" and "bridge protocol version not supported".
hmm, there is a light leak.
The smaller the outer cube the less leakage, but still it leaks.
I tested outer cubes ranging in size from 10m-2000m in 10m increments.
Let it converge fully; the convergence in the scene is only set to 95% (set quality to 0.1 to speed it up) and turn tonemapping off. I also raised the inner sphere up 1cm - the inner and outer spheres bottom surfaces are otherwise coincident. When I let it converge the pink fireflies disappeared at 94% convergence with the 0.1 quality, this is with tonemapping off so the EV for the scene was 0 (but the convergence still uses the tonemapping EV even when tonemapping is off).
I addressed this in the original post, but let me clarify. This is a side effect of doing the job in 4.20, then switching back to 4.16 to run the new job, and leaving the results of both jobs in the archive so I could compare them. Once the switch happened it marked the 4.20 render as incompabitle with the current 4.16 bridge, but has no relevance to the actual results. Switching back to 4.20 then marks the 4.16 job as incompatible with the 4.20 bridge and clears the warning from the 4.20 job. It's just a side effect of switching back and forth, but it wasn't incompatible when the job was run, this is just the results archive.
I trying that out now.
Looks like even more light is getting in after turning off the tone mapper.
I'll let it finish.
But here's the thing.
IF the primitive cube is a solid object.
Then wouldn't @jag11 be correct in saying there is a light leak?
Seems reasonable that an enclosed cube should not have any illumination inside.
So the render should be black for the lack on light penetrating the outer cube.
edit:heres the finished test renders at quality 0.1
Indeed; the physically completely correct result is clear (I tried to check the outer sphere surface for any possible transmission, I couldn't see any), but ray-traciing is an approximation and the result shows that it is pretty much all error. It's not the pink inner cube and its curiously pink shadow (opaque objects do not cast pink shadows), rather it's the massive amount of the noise. The EV setting in the original scene is 13, turning off tone mapping reduces it to 0, so it multiplies the light levels by 8192 (2 to the power of 13). The fact that the top of the cube is mostly white is also indicative of errors (this is partly a result of setting the quality to 0.1, which permits pixel values with very large errors to meet the convergence limit.) Somehow my test didn't produce the same result, I'm not sure why - I ended up with no light even though the render started off with similar errors.
What I think is happening is that it is not a light leak, rather it is a consequence of the precise way Iray approximates the result. It's reasonable to model Iray performance based on the real world but as has been observed wrt the ghost light issue Iray isn't real world - it's ray tracing.
Nvidia broke ghost lights in the pursuit of ray trace perfection, they can "break" this also.
This isn't the only bug/deficiency, or whatever, in iray jag11 has found.
He's got another thread discussing another issue concerning the way light behaves though a prism.
Both seem worth of a bug report to Nvidia in my non-professional opinion.
That suggests the error is caused by the gap at the edges of the surfaces that make up the cube; it's not really a cube, it's six squares arranged as a cube. Consequently the edges don't meet; sometimes they overlap, sometimes they underlap creating a gap. The gap width is constant, but as the edge gets longer the gap area goes up linearly with the size of the cube.