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 don't use iRay or want photorealism at all, but I do think that adding Cycles (and possibly Evee) would be a good move for DAZ. I (possibly wrongly) assume that creating converters between iRay and Cycles would be easier that's iRay to 3DL, it would allow people using both Blender and DAZ to work more freely, and using an actively-supported, open-source render engine wouldn't tie DAZ to any hardware manufacture's whims. I think it would open up DAZ users to more choices, while still letting iRay junkies get their fix.
-- Walt Sterdan
That's never going to happen in any convenient way because of the incompatible licenses under which both Cycles and EEVEE are made available. Graunching the two together would violate the spirit, if not the letter of the license.
But as for converters, we've already got a pretty darned good one by our very own Thomas Larsson and Padone. It's call the Diffeomorphic DAZ Importer. It is really, really good and most of the time one does not have to modify the converted materials at all. I don't think it's going to get any easier than these gentlemen have already made it.
Thanks for clarifying; I (wrongly, I guess) assumed that Cycles at least -- using the Apache LIcense Version 2.0 -- could be used in open source and commercial applications, as a version is still currently being used in Poser. I see that Evee is a different animal of license completely (GPL3), and is also entangled pretty deeply with Blender code itself.
-- Walt Sterdan
Yes, you're right about Cycles; that's a pretty good example of violating the spirit. The GPL2/3 basically says that you cannot link GPL software with proprietary software. That provision is supposed to encourage the development of more GPLed software, and with sound reasoning: If your software benefited greatly from the existing Open Source software made available to you, your software, which also creates some new functionality ostensibly useful to others, it should in turn also be Open Source (the LGPL is a special case for software intended to be distributed as a library). Need a penny, take a penny, have a penny, leave a penny. Makes sense to me.
But developers took no time to find the loophole: they just don't link the GPL software with the proprietary to make a single executable. They keep the two separate and have them communicate with each other over a local socket or some other form of inter-process communication, of which POSIX.1 has many. In that way, the developers benefit from an enormous body of quality software for free, but they don't contribute anything at all back to the community that produced it. That is not what Richard M. Stallman had in mind, but you see it being done everywhere.
Thanks again, very much for breaking it down so clearly for me; the time you spend helping me better understand is very much apprecaited. Thanks as well for your patience.
-- Walt Sterdan
No problem, Walt. I often enjoy the clarity and reasoning in your posts.
This isn't a thread on license terms, it is a thread principally about a specific version of Daz Studio.
I am not talking about reinstating "buggy" behavior of ghostlights -- it is obvious that Daz cannot do that on their own.
I was asking whether Daz can implement fully invisible lights using Iray SDK?
If Iray SDK does not support creation of such light sources (and I would be really surprised to hear it doesn't), then Daz should submit a feature request to NVIDIA Iray team.
Then, if NVIDIA refuses to get their professional rendering engine up to par with other rendering engines used by other DCCs which all support such functionality, Daz should consider switching the rendering engine.
ProRender seems very close to feature-complete, and it is already available in Maxxon Cinema 4D, and also as a free plugin for 3DS Max, Maya, Blender, and even Unreal Engine (which I am sure would be interesting to many people using Daz Studio who are interested in making games).
I am aware that the breakage would be much more significant, but at least it would come with some palpable benefits (acceleration on any GPU, Mac on Arm support, open-source) unlike the recent Iray updates.
Sadly, that is only a partial solution.
As the video drivers get updated, old versions of Daz Studio are inevitably going to either produce artifacts (for example Daz Studio 4.16.0.3 and NVIDIA driver 516.93), or outright stop working or start crashing at some time in the future.
One thing I do agree is that Daz should offer at least one earlier release version for download -- for example 4.16.0.3 and whatever is the current release version. Also, incompatibility with existing assets (if any) should be prominently noted on the download page.
Maxon dropped ProRender from Cinema, 2 versions ago. It may return as, yet another plugin renderer, if AMD gets round to developing it.
Good catch.
I probably meant something like copy the installed folder as it can be used as long as needed if renamed.
Apparently there are suitable atributes listed for iray to make a light invisible to secondary rays (relfections and so on - as I said, that is the problematic bit) but the Iray Programmers Manual says they are ignored and Daz' testing confirmed it (so yes, they did try to do this).
Interesting... are you referring to these attributes that should be possible to set on any scene object (supposedly on lights too)?
The object is visible as a reflection in reflective objects.
The object is reflective.
The object is visible through refractive objects.
The object is refractive.
The object casts shadows.
The object can have shadows cast onto it.
They are described here (under Attributes heading). If that is what they tested, then perhaps it didn't work due to attribute inheritance? If I had access to Iray SDK I would try to create a simple scene with built-in light source (such as point light or spotlight) and set those on it to see what happens and I would also try to disable attribute inheritance on that node just to be sure.
We can shoot this down, but what is the deal with simply providing a fallback version of Studio? If you cannot guarrantee that an update will break a product, then the obvious moral thing to do is to offer the previous version where that product worked correctly. It should be a standard obligation.
Studio is only around 450MB in size. We have new hairs, characters, environments, and all sort of things that exceed that number. I have shader packs that are well over 1GB in size. There should be no issue with having an old version on a server. It doesn't even have to be on the best server.
Also there was mention that previous versions of Daz before 4 were still available for download, and assurances that after DS5 releases, a version of 4 would still remain. If this is the case, what is preventing Daz from keeping a previous version of 4.x available? Why are things handled this way? It is maddening how the current policy is.
Also, I saw on July 22 the Iray Dev Blog posted they released a new version 2021.1.6 for bugfixes. But I don't see a changelog that offers any details. Do we have any details for what this means, and when Studio might get it?
NVIDIA Iray change log, which is in the current Public Beta (4.20.1.58) release.
I wasn't given details, but both the Iray prorammers' manual and Daz testing show that some or all of the attributes in question are (currently) ignored.
Having those details would help getting to the bottom of the issue.
Regardless, I passed this information to NVIDIA and I was told that if Daz needs some functionality in Iray they should just approach Iray team and ask for it if they haven't already.
guess i won't be installing this or any upgrade in the future if i have to keep using that stupid install manager. i miss just being able to directly download and install and not have things hang and crash
This is a beta, those have always required Install Manager. The General Release can still be installed directly.
You dont have to let DIM install it for you. You can just download the ZIP file and install it manually if you wish.
In the past, IRAY has tweaked "convergence" before. The result will usually be longer render-times, which results in more iterations before it is "equally as complete as it was in the past". In the past, it may have thought it was 98% complete convergence at 4000 iterations, but in a new formula, they may have determined it needed 6000 iterations to be 98% complete convergence. That will obviously also take more time.
For quality, you NEED to set a forced iteration count to stop at, not use convergence comparison, unless you want to test how accurate convergence is. For quality, that stopping point at XXXX iteration is what you want to compare.
For the record, an image with "more colors" does not equal "more noise". There could just be better sub-pixel processing, resulting in more variance of gradients. Having 200 steps between white and black can have the same amount of noise as an image which has 500 steps between white and black gradients.
No cure for bad seams, except to increase resolution and down-sample the "cracks", if possible... or increase the "blur", of the rendering quality blending, which is already rather high. The more accurate rendering gets, the more that these minor imperfections will become more visible. It's like comparing old TV to a 4K screen, where you can now see pores on everyone's noses and faces. On old TV sets, everyone looked like smooth plastic. No pores in sight, no wrinkles, no eye baggage, etc.
When it comes to iterations, As a generic rule of thumb, I force a minimum of 1500, or reflections just don't render correct. For a maximum, on a standard image, I have my iteration count to around 5000. For a real good HD image, I might force it to try and reach 20,000 iterations, or just render 4x larger at 5000 iterations. (An 8K image reduced to a 4K image, or a 4K image reduced to 1080p)
EDIT: What i'm proposing is a video card memory manager that is constantly displayed in the viewport., that's constantly updated based upon the visibile state of clothing, characters, props, etc.
I have CPU turned off in DAZ. I only allow IRAY GPU renders. If the memory goes over 4gb in anyway, sometimes it will cause the renderer to disable permanently, and the only way to fix it is to restart DAZ. However, sometimes if I leave it for like 60 seconds, I can get it to work again; but the problem is this process is too time consuming. Has this problem been fixed?
Basically, this is how it should work, god I hope the DAZ devs see this:
1. When you do a render, it should show you precisely how much memory is being used in the video card. If there's not enough video card memory, it should communicate this information to you in the most clearest manner possible. You should be able to guessestimate this based upon what assets are in DAZ; maybe there's already a way to show how much memory is being used based on what assets you have in your scene?
2. When you hide or show clothing or characters, the required video card memory should update in the top or right corner of the DAZ screen.
What i'm proposing is a video card memory manager that is constantly displayed in the viewport., that's constantly updated based upon the visibile state of clothing, characters, props, etc.
Let's say you have 4gb of video card memory, but your scene requires 5gb of memory. It should show what assets are taking up the most memory in the scene, in the viewport itself; a setting that can be turned on/off. Then I can easily hide/fix the assets with the most inefficient texture sizes.
Daz Studio doesn't know how much memory a scene will take when transferred to Iray, so this isn't possible.
Let's say my current scene can't fit into video card memory. Obviously I'm going to start hiding everything in the scene until the render works. But here's the problem, even if I hide everything in the scene except the character, it just won't render until I restart DAZ Studio. Has this been fixed in the beta version?
This is a limitation of Iray, not something Daz can fix.
Use Tech GPU-Z; it's a separate window but it shows you in real time how much memory is being used on the graphics card.
Don't blame DAZ; CHECK YOUR BROWSER. It will swamp your graphics card; I just discovered that Brave (a hacked Chrome) was using 1.6GByte of my 12GByte TitanXP and yet the monitor the browser is using is not connected to the TitanXP (no monitor is connected to it). I've previously had this problem with the mud people, but I managed to deconifgure them. In this case I had to find "Settings/System/User hardware acceleration when available" and now my XP is back to it's standard 142MByte with no clients.
Starting DAZStudio bumps that to 315MByte (not in Iray preview), so I assume that 150Mbyte is the connection cost (duh, when I first started developing UNIX the computer I used had 4MByte of DRAM, end.) Starting an Iray preview (of a scene with just the tonemapping and environment nodes) bumps me to 2.5GByte. Here's the skinny:
2022-08-05 18:48:33.003 Iray [INFO] - IRAY:RENDER :: 1.13 IRAY rend info : CUDA device 0 (NVIDIA TITAN Xp): Allocated 1.906 GiB of work space (2048k active samples in 0.007s)
It's not the frame buffer (I use a UHD monitor, but as I said it isn't connected to the TItanXP). I killed Ruins, which isn't that big, and it made no difference.
So maybe @daz could respond to that; 2GB of workspace for a scene that is totally empty seems like starting on the wrong foot. All the same, there are a lot of other entities to blame too.
4.20.1.58
Yes, they would all have to be set to false but then the ambiguity is what happens to the rays that are not covered in that list.
Rays that are scattered and encounter the object have to pick up the emission of the object yet they have to pass through the object, at 100%, too; otherwise the object still casts a shadow. So the "shadow_cast" property set to false may prevent the latter, but still there is the concept of encountering an emissive surface and picking up that emission while also passing straight through the object.
So... basically if a ray encounters an object and the source of that ray is a reflection or a refraction the object can be seen, but if the ray was scattered by the previous surface the object can't be seen, except by implication of the slightly brighter previous surface.
I'm pretty sure that if anyone analyzed ghost lights in the detail that Iray has been examined here they (ghost lights) would have been found not to work.
Emulation of the RTX functions on a card that doesn't have the hardware (GTX cards and your Titan), takes about 1GB of VRAM and at least on systems that do drive the monitors, W10 takes 1GB just for the fun of it.
So DAZStudio **is** using the whole NVidia ray-tracing shebang? My impression was that the support wasn't in yet, but I have backups so I can roll back to a version without ray-tracing, which version @richard?
Don't know for sure, but the change log mentions integrated version of Iray RTX for DS 4.12.1.8, that was the first time "RTX" was added between "Iray" and the year
http://docs.daz3d.com/doku.php/public/software/dazstudio/4/change_log_4_12_1_118