Re: Some Iray problems
AndyS
Posts: 1,438
Hi,
so you wanted us to show our success with iRay?
When I tried to adapt some of my older sets, I found some bugs in iRay. One I allready reported in that Thread. It shows, that iRay calculates the behaviour of light in a wrong way, that emerges back out of an optical more dense material through the air back to the camera. I really spent some effort to document what is going wrong.
This is indepentant of using the simple parameter setup for reflection / refraction necessary for the old version or applying the new iRay-Uber water shader. The outcome of the iRay-renders is exactly the same.
I reported that via the support line as an official bug report. But the support refused to accept that there are still bugs in the new DAZ release. >:(
And I can continue the list of bugs of the new iRay version. Even in the current new minor release DAZ 4.8.0.59 they're not solved.
So what about displacement?
Even for objects/surfaces with a very low resolution divisions-grid you could apply very small and detailed displacement structures without any problem for the render engine (3Delight).
Now try this with iRay !!
You have to apply division densities which are similar to the structural details you want to implement with displacement. And as everybody knows very well: This drives rendertimes into eternity.
Please find attached the compare of a simple displacement structure rendered with 3Delight vs. iRay. For iRay I supported it with base bump which is, as a buddy told it, a "fake displacement". Yes he's right. Otherwise you wouldn't see any structure (right side)
Do you see the essential important difference in the line where both planes cross each other?
Next:
The environment dome.
What is about the attributes "Environment-..." and "Map-Intensity"?
Shouldn't these parameters not adjust the enironment brightness and the lightness of the dome map seperately and indepentent?
All they do is to increase or decrease the overall brightness of the scene in the same way as exposure time, F/Stop or ISO do.
If this isn't a bug - so I don't know ...
Dear DAZ-Team,
When will you accept the large amount of bugs in the current version and work them out?
Thank you for your attention,
Andrew
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
© 2025 Daz Productions Inc. All Rights Reserved.
Comments
Hi,
I started my new thread over here and in the meantime it landed in "The Commons" ??
--> http://www.daz3d.com/forums/discussion/57935/
So I post it here again.
And please admins, let it over here, cause it is strictly related to the DAZ software.
--------------------------
Hi,
so you wanted us to show our success with iRay?
When I tried to adapt some of my older sets, I found some bugs in iRay. One I allready reported in that Thread. It shows, that iRay calculates the behaviour of light in a wrong way, that emerges back out of an optical more dense material through the air back to the camera. I really spent some effort to document what is going wrong.
This is indepentant of using the simple parameter setup for reflection / refraction necessary for the old version or applying the new iRay-Uber water shader. The outcome of the iRay-renders is exactly the same.
I reported that via the support line as an official bug report. But the support refused to accept that there are still bugs in the new DAZ release. mad
And I can continue the list of bugs of the new iRay version. Even in the current new minor release DAZ 4.8.0.59 they’re not solved.
So what about displacement?
Even for objects/surfaces with a very low resolution divisions-grid you could apply very small and detailed displacement structures without any problem for the render engine (3Delight).
Now try this with iRay !!
You have to apply division densities which are similar to the structural details you want to implement with displacement. And as everybody knows very well: This drives rendertimes into eternity.
Please find attached the compare of a simple displacement structure rendered with 3Delight vs. iRay. For iRay I supported it with base bump which is, as a buddy told it, a “fake displacement”. Yes he’s right. Otherwise you wouldn’t see any structure (right side)
Do you see the essential important difference in the line where both planes cross each other?
Next:
The environment dome.
What is about the attributes “Environment-...” and “Map-Intensity”?
Shouldn’t these parameters not adjust the enironment brightness and the lightness of the dome map seperately and indepentent?
All they do is to increase or decrease the overall brightness of the scene in the same way as exposure time, F/Stop or ISO do.
If this isn’t a bug - so I don’t know ...
Dear DAZ-Team,
When will you accept the large amount of bugs in the current version and work them out?
Thank you for your attention,
Andrew
Displacement isn't a bug - it's how Iray works. I agree it's an annoying limitation, but if that's how the system works - presumably to ensure it stands a chance of fitting into video RAM -then it's not a bug because we don't like it.
I'm not entirely sure I understand your second point, but adjusting the tone of the dome would adjust the lighting of the scene yeas - as long as you are using the dome as a light. Again, that is how Iray works so it isn't a bug though it may be a reason fro you to use a different engine (such as 3Delight).
Duplicate threads merged, and moved to DS forum as per request.
Hi chohole,
thank you for consolidating.
Richard:
Please compare the displacement demonstration. I hope, you see the difference. If your surface really have a 3-dimensional structure, the render engine, whatever, must be able to reflect this correctly. Especially if it claims to be photoreal.
How that could be coded and to take care of rendertime is the responsibility of the software-developers. But it is what you can expect for a state-of-the-art software.
Please find attached 2 small details of older renders. This difference of level is only performed by a suitable displace-map. All the more I expect this from a more modern software (as iRay claims to be).
For the entensities of the dome map:
There are two parameters
- Environment Intensity
- Environment Map
But both only do the same - regulate the overall brightness of the scene as well as the brightness of the sky-map. And the same can be achieved with the camera-parameters. This seems like nonsense, because the names of the above-mentioned parameters implement to perform very different effects.
If you state that it would not be necessary to regulate the sky against the environment brightness, so you should try some of the available commercial hdris. I did and I can tell you that it is necessary to balance the skymap against the environment brightness.
My most important point is the refraction.
I've got a degree in physics. And optics (linear as well as wave-optics) was a part of it. The effect I found on the refraction handling by iRay definately is wrong.
Please take it only as a clarification.
The DAZ-team claimed iRay to be an innovation ...
Anything else left to say? ...
smftrsd72, it sounds like you should be questioning Nvidia about this since they are the creators of the render engine. DAZ has implemented it for studio but they didn't create the program themselves. If there are issues with the realism of Iray then nvidia would be the ones who have to address it.
http://www.nvidia.com/object/nvidia-iray.html
Nothing, I repeat, nothing else out there does displacement like 3Delight. 3Delight's displacement is considered to among the best, if not the best, in the industry. It does micro-fine subdivisions of the mesh, without eating every bit of RAM.
That said, there is nothing wrong with Iray, as far as displacement goes. It just isn't doing it the way 3DL is...and frankly, it can't. Yes, you can get great displacement out of Iray...BUT, you have to manually set the subdivision levels...and set them pretty darn high. So, that would preclude most GPU accelerated renders, as there won't be enough memory to handle all the subdivision. And, even not doing a GPU render, you'd need more than 32 GB of system RAM...unless all you want is something simple with procedural textures, as opposed to image based ones.
Displacement maps in iRay are just plain crap. It's a well known problem that has been mentioned several times. Usually, displacement maps are supposed to create extra geometry. But since it's a map, the engine is supposed to be smart about it. With iRay, it does not subdivide anything. And you have to crank the settings up really high as to make it worthless since you're bumping up subdivisions in areas that don't need it.
Having said that, I don't know if it's just me or if there were changes recently, but iRay's normal map and bump map handling is way better than I remember it just last week. Most of my renders look better recently too. The SSS settings look better without having to convert them. If you do convert them, it looks a bit different and gives it a more consistent look with the rest of iRay materials. One thing I don't like is the iRay skin settings for the eyes. Way too much reflection and glazed look. The regular non iRay settings look way better. To the point where I save those materials before applying the iRay skin settings then re-apply the default eye materials.
You know, most other renderers, that aren't 3Delight have displacement similar/the same as Iray's...that is why bump and normal maps are so prevalent in the wider 3D community...you could pretty much say the type of displacement in Iray is the 'industry standard'. In other words, by having 3Delight in Studio, all these years, we've been spoiled as to how displacement works.
Time ago I read a simple set of rules that I hereby pass on:
1 - create a mesh dense enough to provide a sufficiently "good" outline (the only place where #2 won't help);
2 - create any further details with normal maps.
This works from game assets to "hero" models.
How much slower are you finding the Iray displacement compared to 3Delight?
(Just confirming that you're not increasing the subdivision of the object, because that's not necessary.)
Hi prixat,
please keep in mind, that iray isn't showing the displacement structures at all, as long you're not adding a super-fine divisions-grid.With that, iray will render for an iternity.
Hi Khory,
if I'd do so, nVidia will answer that DAZ is using their product in a wrong way.
And because I don't like these Kindergarten games, I say:
DAZ integrated that new product and is fully responsible only to include correct working stuff.
For refraction it is definately not, as I already showed in my former analysis.
Missing displacement or better: awkward usage of displacement is a further aspect.
Other users found a lot more issues.
I won't withhold that there are some advantages. To get the same natural enviroment lighting of a scene with 3Delight you have to use UE2 with indirect lighting (full bounce). And here, even without special GPUs, iRay is way quicker.
Andy
No they won't. What the will say is "stop using things without enough detail modeled in" because that is the real issue. For years and years people have been careful to keep the poly count low so as not to the hobbyist computers. Many times that is still done even though computers are far more able to deal with the added polys. Modeling a flat plane and then putting a highly detailed texture with a diplamcent map may have saved some time in the old days but that really is not true any more. What we are going to have to see is more realistic modeling rather than faked displacement.
No they won't. What the will say is "stop using things without enough detail modeled in" because that is the real issue. For years and years people have been careful to keep the poly count low so as not to the hobbyist computers. Many times that is still done even though computers are far more able to deal with the added polys. Modeling a flat plane and then putting a highly detailed texture with a diplamcent map may have saved some time in the old days but that really is not true any more. What we are going to have to see is more realistic modeling rather than faked displacement.
Exactly...
As I said in another thread...
The more realistic the renderer, the more realistic the geometry (mesh) needs to be.
++++
And if Iray did NOT have all the lighting, surface model and volumetrics shadeops compiled into the core (kernel) then you would need to use something similar to UE2 (full bounce), too.
Yes, in 3Delight, there are enough shadeops built into the 'core' that you could do full GI, without using a shader, like UE2, but you'd have to have some sort of scripting to hardwire the commands when building the RIB file to render, so why not just use a shader that can call what it needs and add to it, if needed? 3DL shaders (not the 95% of the stuff in the store called shaders) are actual programs that add functionality to the base 3DL.
Iray is pretty much limited to what is built-in (and there's a lot built in). Most of the DS 'shaders' are just providing a UI to access them or just passing values for the variables.
So just because you need to use a shader, doesn't really mean anything. I know of half a dozen ways to get full GI lighting in 3DL...beside the two already mentioned...each of them different from the others.
Ah, so this is the "basic flaw" I mentioned the other day in this thread? Looks like that's half of my problem dealt with, although I'd still like to know if the bump value glitch on 3Delight>Iray conversion is really a glitch, or if it's supposed to work like that.
It is a damned if you do, damned if you don't sort of thing. Do you build for a computer with low potential so that no one gets hurt feelings when it is too much for their computer or do you build for what would be far closer the sort of standard that will give more far more realistic results? I am starting to feel like we have spent way to long trying to build for computers that can't handle a reasonable volume of poly's for most reasonably current computers. In some cases we can get around low polys with smoothing but that is just not going to cut it with many things going forward.
Amen.
Yes, most of what I've put up for freebies is still pretty low poly, but the stuff I've made for myself or am still working on, much, much higher.
Hell, when some of the current games are making running character models in the in the 15 to 40K tris range and the main character figure in DS (at base res), is under 20K (quads...40K tris)...think it's time to up ante a bit?
After all, isn't this software primarily used for creating static images? (yes there's quite a bit used for animation...but isn't the bulk of the usage just static images?)
I think it is for things like props and environments yes. It is past time.
But Khory sorry,
don't you see the disadvantage out of your approach?
With the philosophy of reusing tilable maps you're more flexible in designing different sets of very different size using the same base texture maps. With your approach you have to build each set from zero on with all objects with all necessary details again.
But I see .... it is fruitless.
Hi Khory,
No they won't. What the will say is "stop using things without enough detail modeled in" because that is the real issue.sorry, but you got it wrong.
Here I was referring to the not physical correctly working refraction. That's an absolute NOGO.
It's still possible to use displacement for some kinds of detail, but there needs to be enough resolution in the base cage mesh to support the detailing with a manageable level of SubD. Modelling for 3delight/Firefly (and other engines, such as the modo renderer I believe) it is possible to use very large polygons in places and to provide fine detail via a displacement map. For Iray and other engines using a similar system that doesn't work as extremely high levels of SubD are required to get enough vertices in the big polygons, resulting in a huge number of unneeded polygons in areas that are already more finely divided (such as bevels around the big polygons). That means that content made exclusively for 3Delight/Firefly will not always translate easily - it really needs the detail split between displacement and normal maps, as suggested elsewhere, or the larger polygons broken down without dividing other areas of the mesh, or both. It is going to take a while for both users and creators to adapt to this.
I've been making and selling tillable textures for about 8 years now so I fully understand how they work. And, I will continue to do so going forward. I already have done 3 for Iray that use tiling textures. I also am aware just how few I have done over the years that really required displacement to get a realistic look during a render. Your example of a tile wall is one where a normal map would more than suffice to give a realistic surface.
Like button pressed.