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
Please let's get back on topic. Can anyone confirm the issue with geoshells in 4.15.0.9?
I haven't been able to reproduce this with G8.1F. Maybe I'm not looking in the right place. Please show some screenshots of the problem you see. What character you are using? What is not correct (pokethrough? black marks?) What body part(s) show the problem? Does it show up with just a plain white geoshell with the offset changed to 0.010, or is it a specific geoshell product that shows the problem? What is your Instancing Optimization set to (auto, memory or speed)? If not set to speed, try speed; there are issues with the memory setting.
My understanding of the previous explanation is that the centre of the Iray view origin can be adjusted to match the viewpoint origin (minimising math errors due to a spurious offset) but that this does not always happen. Once it has been adjusted from (0,0,0), or wherever the initial setting is when a scene is loaded, then going back to the original centre is going to leave corresponding math errors in until the (Iray) viewpoint/origin is reset. I can believe that turning the visibility of something in the scene on/off will reset the viewpoint - it certainly causes the whole preview to be set up again - and I can also believe that DAZStudio still has problems with adjusting the viewpoint at the right time causing preview errors (maybe justifiable for performance) and render errors (definately a bug in my opinion).
Of course reproducing this without a detailed knowledge of how DAZStudio handles it internally would be very difficult.
Well, as I said earlier in the thread (and I think Dr. JellyBean managed to reproduce it), an example would be wet (or dirty) skin geoshells. It shouldn't matter which product you use, and as far as figure is concerned, G8F is what I am using.
The problem I am seeing ranges from triangles in wrong color (not necessarily black) to outright invisible triangles (i.e. opening a hole in the underlying figure geometry) depending on how far off the scene center the figure and the camera are.
Instancing optimization is an interesting point -- I just tested this case of artifacts I was seeing at -415 ZTrans with 4.15.0.9, and it turns out that if Instancing Optimization is set to Auto there are artifacts. However, setting explicitly to either Speed or Memory appears to fix the problem.
However, further testing with a scene where the figure is at -6565.896 XTrans shows that actually only Instancing Optimization set to Memory fully fixes the problem.
Another bug I just found while testing this is that if you set a custom scene file in Edit -> Preferences -> Scene -> On New DAZ Studio will not load backdrop preset from the scene file. Both Backdrop Color and Backdrop Image "Record settings when saving a scene file" are checked, and respective "Ignore settings when opening a scene file" are unchecked and the .duf file configured to load on New actually does contain those settings.
Finally, the Preview Lights option is never saved anywhere which for me is really annoying because I always want it off.
Can anyone confirm whether or not the new beta fixes the issue with opacity maps not working correctly in iray?
Public Beta (4.15.0.12)
Source maintenance
Setting the maximum number of recent open files (via API) now persists between sessions
Updated public API documentation; DzContentMgr
Explicitly enable Iray instancing shift (Render Settings > Optimization > Instancing Optimization) for “auto” (Auto) and “on” (Memory) states instead of relying on default/initialized value
No material impact on precision issues with close surfaces on objects positioned far from world origin
Force update of scene shift for each frame of an NVIDIA Iray render
No material impact on precision issues with close surfaces on objects positioned far from world origin
Force update of scene shift if the camera moves for the NVIDIA Iray DrawStyle
No material impact on precision issues with close surfaces on objects positioned far from world origin
Fixed FBX exporter support for text actions in morph rule settings; Bake == 0; Export == 1, Ignore == 2
DAZ Studio : Incremented build number to 4.15.0.12
Cool. Anyone dealing with anomalies regarding large camera/figure distances from scene center should definitely try this latest beta as this should clear most things up.
Here is the official Iray explanation for why playing with that control does what it does:
3.6.2Increasing computational precision and accuracy
When instancing mode is set to “on”, “auto” or “user”, the scene is automatically shifted in space. This increases the precision and accuracy of rendering computations and reduces precision artifacts that originate from self-intersection. To disable this behavior, set bool instancing_shift_camera to “false”.
It is also possible to force an update of the scene shifting by calling the API method IScene::set_dirty at the beginning of a frame with a flag value that marks the instance transforms as dirty. This is recommended if the camera was moved a long distance (like when rendering new frames of an animation, or the user interactively changing it over time), as there is no automatic update of the shifting in order to avoid unexpected stutter through scene updates when moving the camera.
In other words, the act of switching Instancing Optimization between its possible options triggers an invisible scene space shift - thereby fixing (in most cases) the problem. It isn't any one value of Memory/Speed/Auto that does it. Having said that, this latest beta should make it all automatic now.
Make a backup before installing 4.15.12 (I didn't, of course).
For me, it's the worst crash bug I've ever seen in a DAZ beta. Wont run for longer than a minute max. Looks like something around nVidia (neuray), updated to the latest Studio driver, no change.
Load a figure, it shows and renders. Apply a pose, then the grayscale preview has the new pose, but iRay still uses the old pose. Rendered figure keeps disappearing and coming back. 100% CPU load, and soon a crash.
This *may* have started after I applied PBRSkin for the first time, but it now happens with any figure (curiously, plain G8F is the worst, it crashes immediately on first render).
Update: Seeing a lot of this in the log:
2021-02-19 22:21:52.697 WARNING: ..\..\..\..\..\src\pluginsource\DzIrayRender\dzneuraymgr.cpp(359): Iray [ERROR] - API:DATABASE :: 1.0 API db error: DB element "DS_the_draw_scene_11" is still referenced while transaction 444 is committed.
2021-02-19 22:21:52.697 WARNING: ..\..\..\..\..\src\pluginsource\DzIrayRender\dzneuraymgr.cpp(359): Iray [ERROR] - DB:DATABASE :: 1.0 DB db error: Finishing edit after the transaction was committed or aborted.
2021-02-19 22:21:52.705 Iray [INFO] - IRAY:RENDER :: 1.0 IRAY rend progr: Received update to 00097 iterations after 2.933s.
2021-02-19 22:21:52.814 Iray [INFO] - IRAY:RENDER :: 1.0 IRAY rend info : Updating geometry.
2021-02-19 22:21:52.815 WARNING: ..\..\..\..\..\src\pluginsource\DzIrayRender\dzneuraymgr.cpp(359): Iray [ERROR] - API:DATABASE :: 1.0 API db error: DB element "DS_the_draw_scene_11" is still referenced while transaction 446 is committed.
2021-02-19 22:21:52.815 WARNING: ..\..\..\..\..\src\pluginsource\DzIrayRender\dzneuraymgr.cpp(359): Iray [ERROR] - DB:DATABASE :: 1.0 DB db error: Finishing edit after the transaction was committed or aborted.
Update: workaround for now is to switch to Filament and back to iRay after every geometry change; this seems to force an update of the iRay state.
Playing with the Shaders seems stable, as long as the geo is not altered.
this force update thing sounds like it will make animations slower, I haven't tested it yet
Thank you, this is being investigated.
I suspect it won't because each animation frame is pretty much a new Iray render.
Wow, there are some serious lag issues with simply navigating with the perspective view cam when in Iray mode...
Also, you cannot apply PBR shaders to geographed props such as genitals, this is truly a crappy beta that has stumbled, tripped, and fell hard backward!
But then again, this is a beta after all, it's a good thing I made a backup!
EDIT: Now I'm back to where I started, no harm no foul!
Sorry, but this doesn't seem to be entirely correct.
For me it was the Memory value that fixed it -- if it was the switching between values, then switching from any to any other value would fix it which simply did not happen.
As for whether this latest version fixes it properly, we'll see. From the changelog description it sounds like it may add considerable slowdown when moving perspective camera in Iray preview mode.
I've just received the latest beta. I didn't know about the other problems, but when viewport is set to iray preview, the camera movement performance dropped like a rock (iray photoreal). I can't properly orbit anymore. Any scene with any character. What might have happened?
When i download a new version, i drop whatever it or they are in some folders - takes about a minute - much quicker than whining about the lack of version control; I handle my own.
... And yeh, I've also reverted to .09; as you say it's beta - a massive indicator there are going to be issues. I can live with the ones in .09.
Yeah, I hope it's a recognized bug, and not a feature, as we still have the mouse-focus bug where the cam/perspective view gets skewed if you scroll-zoom with the mouse!
They only fixed it for certain brands of mice and not universally; the current iray-cam and PBR bugs have killed all work-flows, and NO, I don't care for any workaround, but an actual solution as it is something that someone messed up within the code!
Yeah, these latest bugs are all the more reason to back up your programs if you plan on using the beta releases, it's just natural that betas will have issues as that's the nature of betas I hope they are aware of these bugs though as they are pretty big ones!
My bad - you're correct. Switching it to Memory (aka "on" as per the Iray SDK documentation) or "user" (not currently implemented in Daz Studio afaik) is what triggers the re-calculation. Off or or Auto won't do it, unless your scene is already set to Memory. In which case the act of setting it to Off/Auto and then back to Memory is what should trigger it.
It may be just the way I have my Iray preview settings tuned to be on the snappier side (although I've tried resetting them to defaults and so far behavior is unchanged) but this current beta is giving me instant crashes any time I try to so much as move my camera view while Iray preview is enabled. Given that Iray's own documentation states that the reason for not making sceen coordinate re-calibration an automatic thing in the first place was because of the potential for stutter/errors resulting from liveview camera movement:
Imo Daz's developers would do better to dispense with auto recalibrating the scene coordinate plan on camera movement and instead implement a menu option somewhere (perhaps in the Render Settings pane's triple-dot menu) to "Recalibrate Ground Plan" that would be a simple call to the set_dirty Iray API method bolded above that users can resort to when the need arises.
Has the beta been pulled? After I install it, it shows up with '?' in DIM and no files were installed.
Try uninstalling and re-instaling it, making sure nothing is running when doing so.
As I said above, I disagree with having a button for that -- regular user has no chance to know when they should press it anyway unless they happen to read Iray developer's manual like you and I. IMO, program should be intelligent enough to know when to call it and it shouldn't be hard to implement that.
What DAZ developers probably did wrong is they added set_dirty() call on each WM_MOUSEMOVE message received while the user is dragging camera controls (which can be hundreds of messages per second especially on high-DPI and fast polling mice) as opposed to only when left mouse button is released (WM_LBUTTONUP) or only when user pauses dragging for more than X milliseconds. I bet that's what is killing the performance in Iray preview.
Imo the best way to handle that would be to have it both ways - implement an algorithm to have it done automatically (at a much less frequent rate than current, obviously) to service beginners and have an obscure menu option to trigger it manually asap for when the need arises among advanced users.
One other thing about having these coordinate plane updates being made automatically. As per the DS changelog (quoted here) for 4.15.0.012, coordinate plane updates are automatically being made:
Currently buggy behavior aside, while this would seem to solve the problem of precision artifacts in virtually all situations, there is one way of composing a scene whereby this automatic re-calculating will make it virtually impossible for a user to render that scene without precision artifacts appearing:
Prior to now, Daz Studio/Iray uses either the default 0,0 plane location or updated camera position to orient where mathematical zero is currently located in a scene. The thing is, technically precision artifacts become visible in a render whenever the mathematical center of the scene is distant from the figure(s)/object(s) being pictured - not distant from the camera or an arbitrary 0,0 location. Prior to 4.15.0.012 you could crudely account for this in scenes with large subject/camera distances by moving your figure/object to its intended (distant) location, moving the camera to that same location, toggling Instancing Optimizatiuon to On or Auto for a second, and then moving the camera back to its intended location before initiating a render. With the scene's mathematical center being automaitcally tracked to camera location there will be no way to achieve this same sort of workaround - unless there exists in an advanced menu somewhere a way to turn that auto tracknig off.
Agreed; fixing that expert situation, once the current issue of precision artefacts in common user scenarios is fixed, is certainly a valid and useful feature request. Indeed I can easily produce animations where the character is at 40m; I'm currently working on one using "Beneath Fire Mountain" but it doesn't look so far like I can possibly make it render in finite time and that makes the artefact issue moot. I need the Iray origin to track a figure; everything else tracks that figure. In other cases I need the Iray origin to track the focus of the camera, indeed that is what is actually happening in the animation I have and it is sufficient I suspect for most situations since it is trivial to set the camera focus to a figure (or, indeed, any object) using the keyboard shortcut.
While I could repro the artefacts with a 1000mm camera 80m distant from a G8 figure in 4.15.0.9 with 4.15.0.12 I cannot. I do see artefacts if I rotate the figure in Iray preview but they disappear as soon as I stop rotation. I'm using exactly the same test scene I used before (I remembered to save it this time :-) There are no artefacts when the scene is rendered. I saw brief artefacts with Filament but none in a Filament render. I haven't tried camera rotation in Iray preview, only figure rotation; camera rotation is rather pointless in my test scene and I have another Iray render running in parallel using 4.15.0.12 and I don't want to damage it (it is at 94.69%...)
I did discover a "hang" bug that happened on a completely new scene without even touching Iray. I had loaded the Mad Lab scene +broomall and prop +ctableall. I deleted the table lights and rotated the scene then got this hang:
I don't know if this is related to the changes.
The Change Log certainly does not say how the "scene shift" is actually set. The obvious way is to set it to the center of all the close objects for some definition of close. Certainly using the camera origin is inappropriate; at least the scene shift should be such that the closeest vertex visible in the camera frame is close to the scene origin and, realistically, the scene origin should be somewhere beyond that. It looks like the origin is somewhere close to the figure in my simple test scene, but my camera focus was also set correctly (that's how I know the figure is 80m from the camera!)
Getting Fatal Error anytime I move the viewport camera in iray mode. No matter what model I load. Started after updating to 4.15.0.12
"Fatal Error - Access of invalid tag 3674"
2021-02-22 21:00:40.114 WARNING: ..\..\..\..\..\src\pluginsource\DzIrayRender\dzneuraymgr.cpp(359): Iray [ERROR] - API:DATABASE :: 1.0 API db error: DB element "DS_the_draw_scene_195" is still referenced while transaction 28 is committed.
2021-02-22 21:00:40.114 WARNING: ..\..\..\..\..\src\pluginsource\DzIrayRender\dzneuraymgr.cpp(359): Iray [ERROR] - DB:DATABASE :: 1.0 DB db error: Finishing edit after the transaction was committed or aborted.
2021-02-22 21:00:40.121 WARNING: ..\..\..\..\..\src\pluginsource\DzIrayRender\dzneuraymgr.cpp(359): Iray [FATAL] - DB:DATABASE :: 1.0 DB db fatal: Access of invalid tag 3674
Keep in mind that he thing being shifted here is the Iray renderer plugin's internal zero reference ponit in virtual scene space - not Daz Studio's reckoning for where zero in scene space is (ie. if you check, no x,y,x coordinates of objects in your scene change when these adjustments are being made.) Consequently the only control Daz's programmer's can exercise over this is whatever is currently made possible by the Iray plugin's API. If you look through relevant portions of the Iray API's official documentation (not to be confused with the Iray programmer's guide - what I am usually in the habit of citing here) the only way in which control over this has been considered or addressed is in reference to camera position in scenes with lots of instancing going on (hence the combo functionality of the scene instancing mode control.) Since use of instancing can much more readily lead to issues with calculation precision than most other uses cases. For any of this to work any other way than camera location, Nvidia/Iray's developers would need to be involved.
This is under investigation.
4.15.0.13 fixes the camera/view rotation bug. Rotation in the Iray preview also seems to me to be faster, but then I didn't do it in 4.15.0.12 :-)
There's a comment in the Highlights about improving the release of Iray assets on rendering, but I still see Iray preview perma-hogging several GB of GPU memory when it is switched off. I did encounter a problem with .12 where rendering shortly after turning off an Iray preview (I always turn it off before rendering) resulted in an unexpected OOM, I tried the same scenario in .13 and didn't get an OOM but I don't even know if the .12 problem was reproable (I didn't try to repro it).
It's not clear to me if the geoshell offset math errors are fixed in .13; I found a test case I hadn't been aware of before and am now finding geoshell errors, but I didn't test the large-offset case with .12.
The 'neuray' errors and crashes are gone. Works really well so far, glad to be back on the beta.
Thanks @development for the rather quick fix.
YES!
Now I can upgrade in earnest; thanks DAZ for addressing one of the bugs, I'm wondering if the Geograph/Genitals can have the PBR shaders applied, unlike with 4.15.0.12...
I updated to 4.15.0.13 from 4.15.0.9 using DAZ Install Manager, and here is what I was greeted with.
1. Yep, as if I never started the program before.
2. I can't see any links or checkboxes, GUI is totally messed up.
3. When I close that window by clicking on X (because I can't see GUI elements on it properly) I get the other window which doesn't resemble DAZ Studio at all.
Now what?
EDIT: I relaunched DAZ Install Manager and it was still showing an update as if it was not installed at all! I let it install the update again, and now it works.
How did it manage to do that?
That usually caused by updating while Studio is running. Un-install then re-install being sure Studio is not still running.