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
Speaking as someone who has a card that can do TCC (Titan RTX), I can tell you it does bunk all in Daz and made using Daz a pain in the ass. Set it back to WDDM after a week of trying it out.
what you describe is happening with most other HDR images but those particular ones are the problem it seems DTSS-Substance-#.HDR
I actually think they are meant to be textures but I have all my HDR files copied to one folder for ease of access
https://www.daz3d.com/strange-substances-pack-2
they render fine with iray but Filament just won't accept them at all, they show in the parameter thumbnail
I want them for scifi effects
A Titan XP in my case. It took me the length of time to discover DAZStudio doesn't support dForce; I had previously compared the Titan XP dForce with the CPU dForce and discovered the latter was unusably slow (I do do a lot of dForce) and that it didn't actually produce the same results as the XP; at the very least the explosions were different. Since I use dForce so much TCC mode is not an option, unless I buy another one specifically for dForce, or maybe something cheaper that does OpenGL well (I think that is what dForce requires.) The problem is that the XP on Amazon still costs more than the 3090 on NVidia's site; $1900 for an XP on Amazon, $1500 for a 3090 on NVidia. Amusingly I apparently have a valuable antique; the Titan XP [Founder's edition no less] I got from NVidia on 1/16/2018 cost me $1200, $700 bucks profit, probably have to declare that. eBay calls [not].
Maybe I should just work out how to script Iray renders, then I could pull the XP out of my current rig, plonk it into a headless bitcoin miner style setup and just let it render the multi-hour renders I have the XP for elsewhere (in the garage to be precise). So long as I have an on-board GPU to do test Iray renders a little faster than the CPU that actually runs the edit end of DAZStudio and to run dForce PDQ that would work. I don't see any problem mirroring my content library to a render rig, that's an excellent application of rsync.
Good to know, ty
As a fellow Titan RTX owner, can also back this up. The rendering performance gain you get (something like 5-8%) from TCC mode simply isn't worth the practical drawbacks of not having the (likely) most multi-tasking capable graphics card in your system available for general graphics purposes.
If you haven't yet, you should give Iray Server a try (the first month's a fully featured free trial.) Not only does it handle all the Iray render batch processing/cueing for you, it makes needing to duplicate your Daz content library between computers unecessary. The only downside (other than it being subsciption-ware after that first month) is that Daz has yet to tap into Iray Server's built-in animation rendering capabilities (which are actually quite powerful) available through the Bridge portion of the Iray API.
I've not tried using a texture for an HDRI until now. I have used some of DimensionTheory's HDRIs. I just played with Platinum Pack 1, the room scene, and it seems to behave just as expected in Iray and identically with Filament. The camera seems to be set 140cm above the floor and I think the dome may be tilted wrt the horizontal plane; I had to tilt my camera -1.2 degrees to get the near verticals vertical (using an 18mm lens to get a 90 degree FoV).
When using a simple rectangular image Iray maps it in the [inverse of the] same way it maps a dome to an image with the lens distortion. I used a 5184x3888 TIFF I have of a picture of an ice flow in Iceland, it's not exactly 2:1 aspect ratio, so the Iray mapping squishes the image, but the spherical lens distortion does reproduce the original image (the dome is rotated 90 degress in all these examples, this is why the "join" is down the middle):
So that really is the original image demonstrating the transform Iray uses (by the absence of any net transform, other than the squish). When I render the scene in Iray using a 9mm lens (to get a 120 degree view) I get what I would expect. When I render with Filament I get Ruins; so Filament ignores the set dome and goes back to the underlying DAZStudio default:
Iray:
Filament: 
Iray rendering with the default (Ruins) background: 
The difference in the last two renders is down to the 2EV difference in speed of Iray vs Filament; Filament is 2EV faster than Iray. (There were also issues with the falloff of DAZStudio lights in Filament vs Iray, but I have not checked if those have been fixed.) I guess just using a backdrop, not a dome, will probably work correctly although it won't provide any light. An easier approach is to convert the texture into an HDRI using Iray, spherical lens distortion (2:1 aspect ratio), no tonemapping and a canvas; that converts the TIFF/PNG/whatever from the dome into a .exr which Filament should load correctly.
weird as it is in HDR format and Filament happily loads HDR I made myself from 360 and other images converted in Gimp
I can try saving it from Gimp of course
Facebook is fussy about the 2:1 ratio for 360 so that could be it
According to the web page DimensionTheory used HDR because the images have high dynamic range data, i.e. pixel values outside the range of sRGB, but the images are still rectangular (like my TIFF). The high dynamic range isn't necessary for an environment dome but the image does need to be spherical; when DAZ/Iray maps my Iceland TIFF to an environment dome it is making some totally arbitrary decisions about how to do it. So long as the rectangular images tile in X (horizontally), which of course my TIFF doesn't, the method I suggested will map the HDR rectangle to a seamless spherical HDR. The GIMP or PhotoShop can probably do that as well and would give you more control; since the images are actually square (2048x2048) a better mapping might be to join the corners together, i.e. map the center of the square be at (0,0,-inf) and the corners (all) at (0,0,+inf). I'm assuming the squares do tile on all edges so there won't be a seam, there will be distortion away from the center but it will probably be less obvious that the distortion which results from the default Iray behavior above (if you can see the images I posted; I should probably have re-encoded them as JPEG...)
It isn't enough for the API to be available, it has to be matched up to DS (or rather, vice versa). The fact that it isn't currently supported doesn't imply that daz is ignoring the feature.
To the best of my knowledge, the following DS changelog excerpt is the most recent official update made by the Daz development team regarding its progress on implementing animation rendering support via Iray Server:
DAZ Studio : Incremented build number to 4.9.3.163
Source maintenance
Support for remote rendering via NVIDIA Iray has been updated to include the “batch” render mode for individual frames; support for animations requires more extensive/risky changes and is therefore not currently provided
Relabeled the “Cloud [BETA]” page, found on the Advanced page of the Render Settings pane when NVIDIA Iray is set as the active render engine, to “Bridge [BETA]”; this is consistent with the name now used by NVIDIA to refer to the feature
Added a “Connection” option to the “Bridge [BETA]” page for NVIDIA Iray > Advanced; allows a user to choose between “Iray Server” (default) and “Visual Computing Appliance (VCA)”
Added a “Port” option to the “Bridge [BETA]” page for NVIDIA Iray > Advanced that is displayed when Connection is set to Iray Server; allows the user to set which port on the server to communicate through
Encapsulated options on the “Bridge [BETA]” page for NVIDIA Iray > Advanced that relate to the “streaming” remote rendering mode in a “Streaming” group box
Added an “Add to Queue[…] button to the “Bridge [BETA]” page for NVIDIA Iray > Advanced; clicking the button will prompt for a Job Name if the Image Name property, found in the General > Destination property group on the Editor page of the Render Settings pane, is empty; clicking the button will use the specified configuration/authentication data to connect, upload the current frame of the scene and then disconnect
Extended DzIrayRenderer scripting API; added exportRenderToBridgeQueue()
Made changes to avoid [re]loading images for Iray Bridge renders once animations are supported
Made changes to naming of Iray Bridge snap shots; now uses jobName % '-' % frameNumber % '-' % uniqueName
This statement is currently more than 4 years old... and if you go to the
Bridgetab underRender Settings > Advancedin even the most current Beta release of Daz Studio (4.14.1.38), you will see that the feature implementation for Iray Server rendering remains identical to what is described in this 4+ year old changelog.And as you stress, it says "support for animations requires more extensive/risky changes and is therefore not currently provided" - that suggests they are going to proceed with caution, and that it may have to wait until they are going to have to make changes in the related areas anyway. We don't know how far-reaching the changes would be.
Just a heads up for the animators; with the latest beta, there is a very serious trigger (somewhere) which causes undo stack to completely mess up and not register any of the changes made on the scene. In my case, undo stack bugging after;
- Changing total frames incrementally to >= 500 (evey time an animation is added/edited between 50 towards 500)
- Timeline frame starts from >=50
When the bug triggers, whatever change you made on the scene is ignored and the last undo point always becomes "Undo change total frames >500". All other actions are missing from the undo stack. Translations/rotations/etc. (Yes I always work with TRSOAH, and never uncheck them)
Trying to create a scenario where this happens again. Just a warning though...
Edit: When I checked the log; the time it was bugged, the shutdown sequence of the DAZ showed the following without any other information in the log:
2021-01-05 20:45:09.689 Clearing Undo Stack...
2021-01-05 20:45:09.965 WARNING: ..\..\..\..\..\src\sdksource\general\dzundostack.cpp(739): DzUndoStack::clearAll() called with a non-zero hold level. Possible unclosed beginHold().
2021-01-05 20:45:09.966 Deleting Scene...
2021-01-05 20:45:21.565 *** Scene Cleared ***
Guys, I'm getting this error randomly in the beta version. Is there any fix available? I got a gtx 1080ti and a 2080ti and I'm using the latest game ready drive (460.89).
@GutoCrafts:
Does it also happen if you render with just one card?
What is the VRAM usage on each card when this happens?
You didn't exactly give us a lot of context here.
Hi! The later versions of Daz Studio have begun to ignore my GPU. When unticking the CPU and only using my Graphics card, DAZ Studio refuses to render. Will this be fixed in 4.15? As for now I can only render using my CPU.
is it an older unsupported card? I think gtx6## series and below no longer are
4.15 beta is here. Most silent minor version update of Studio I've seen.
Currently, the Higlights thread doesn't show change log yet.
The Change Log itself has been updated.
The 4.15 general release seems to be there too...
4.15 hasn't fixed the issue of environment settings not being saved if the map is set to none...
I think it is a bug in reading the scene; 4.14 is saving the environment settings (e.g. turn on "Draw Dome") but it seems to ignore the "image":null entry; turn on "Draw Dome", save the scene, read it back in and "Environment Options" gets created but the map is set to Ruins. A Render Settings... preset will, however, set the map to None as in the attached Render Settings... preset (I edited it to remove the Iray and General settings that remain even when they are not selected):
It looks like no improvements have been made to the long open/load/close times in 4.15. Here are the results from timing (mainly based on times in the log file) for a test scene with architecture, props, a dome, 2 G8F and one G8M:
Scene load time: 4:04.371 (from log file)
DAZStudio close time: 3:58.118 (from log file; "Deleting Scene" to the last entry in the log file).
Close time with my work-round: About 1 minute (based on the time from the end of the load to the last entry in the log file - almost exactly 1 minute).
There seems to have been a correction to the 2EV overexposure problem in Filament rendering; I'm still checking that out but the viewport Filament rendering is now much closer in exposure to the Iray render.
That's incorrect. The 2EV bug with respect to dome (Environment Map) illumination is still present.
Just updated to 4.15. I disabled my CPU in both interactive and Photoreal modes.
Rendering happens with no issues in both modes. Pretty fast too. Graphics card is a GTX 1060 with 6GB.
I'm getting the same issue as 4.14 - opening the program brings up the splash screen, the main program window appears and within a couple of seconds it freezes - no element responds to mouseover or click. hen he program just closes. The last few lines in the log file are:
So it seems to be an opengl issue...
I'm running this on a 4790K cpu (iGPU disabled), 32gb ram and a 1070ti.
Any ideas would be appreciated. As stated above, I've been having this problem since 4.14 beta so presumably Filament related? I won't try a 4.14 or 4.15 main release as that would overwrite my only working version (4.12).
It does work on my laptop, 8750H 16gb + 1070 8gb.
What is the OS version,video card and driver version?
Just downloaded the Beta and loaded an old scene. Clicking on the Render button opens up the Save image window.
It's probably because "Render Target" option is set like this in Render settings? When there's no filename in "Image Name" text field, like in this screen shot, "Save Image" window will indeed pop up.
Thank you. That was it although I have never changed that from New Window since I started using Studio years ago :)
Where? It's not in my product library. (and just for the record; I don't use any content mangler systems, strictly manual dl and install to my specific installation needs for my content and various 3d-programs setup)