Is Iray Render Speed Mostly about Lumens?
I've never had a render take longer than 5 minutes per frame (for animation). But my current comp will render for 15 min and still be pixilated. I'd toggled the Tone Mapping settings to no avail. Is this just about lumens? If I crank all the light sources from 500K to 2 million, is that the trick to making renders go faster. (Hasn't worked so far.)
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
That's what I've read in the forums but I am somewhat doubtful if that is the truth. I think brighter light makes the scenes brighter washing out alot of the visible pixelation that is easier to notice in dimmer scenes. The pixelation is still there, it's just less noticable.
The other thing I've hear is more different lights coming in a different angles in a scene will make a scene render faster because more light is reflected in more directions which will light the areas with less light more quickly because they now have more light thereby reducing noticible pixelation.
The problem is is if you are making an animation the dramatic effect of your light is important so it's not a good ideal to wash out your scenes with light.
You should try rendering at a small size, say 320x240 or 640x480 or otherwise recontruct your scene using 3DL shaders or toon shaders or buy Carrara if you aren't using Genesis 3 products. I'd think it'd be another 5 years before you can do iRay scenes affordably with entry-level consumer computing hardware if not much longer if you go for FHD or 4K size animations.
If you've ever followed Blender at all you'll notice the animations are invariably some sort of variation of a toon style although Blender is capably of producing realistic looking still renders.
I answer this question often. Iray renders by calculating light samples to pixels. The more light samples, the faster the convergence. A brighter, more evenly-lit scene will provide more rays. Therefore, *all things considered*, it'll render faster. That said, there are MANY things that affect render speed, so there's no one setting or solution that works all the time. Scenes with indirect light, even when overly lit, will still take a long time to render. There are WAY more light calculations that have to be made with indirect lighting.
I'm not sure what you mean by "pixelated" but if you mean the salt-and-pepper look of pixels, that's the effect of under-convergence. (Pixelation is a term for something else, where the apparent size of the pixels is enlarged in relation to the display capabilities, as would result in a low resolution photograph on a high resolution monitor.) Convergence is when a certain proportion of samples to a given pixel start matching up (among other factors). When this proportion reaches a threshold, that pixel is considered converged. But convergence also appears to be affected by a "noisy" materials such as the metal flakes layer. With these, it can take 2-10X as long to reach the default 95% convergence, even though the scene is actually done. Iray just has a hard time determining that.
If you boost the lighting level, you can easily reduce the tone mapping settings to compensate. That's what they're for. The mistake people make is to think that by adjusting tone mapping settings in an underlit scene they'll get good rendering times. It doesn't work that way. The tone mapper does not alter the amount of light in the scene, only the amount of light that reaches the Iray "camera."
OK., thanks.
But which is it that should be done? Can I increase for example the intensity of a studio light to be extremely bright or do I need to add more lights from other angles to get an increase in rendering speed?
How long is a piece of string? This isn't an answerable question, because it "all depends."
What is this "studio light" you mention? If it's a mesh light, those already suffer from slower rendering, simply because of the way they work. The fastest results come from:
A) The HDRi environment light
B) The built-in light types: spot, point, distant
There are some mesh light products for sale in the Daz store that are pretty good, and designed for reasonable performance. There are some others that are just dreadful. I won't name names, but just because it's for sale doesn't mean it's any good.
Adding more lights doesn't always resolve the underling issues, because that's just more light paths for Iray to calculate. On average, though, adding more lights is better than having fewer dark lights. So this is one possible solution.
Some scenes/computers are just slow, no matter what. It's the nature of realistic-based rendering to require processing time. If your aim is a moody scene where it's mostly dark and all the light is indirect, you're in for a long wait.
OK, I will proceed on then as usual and maybe the AMD ProRender open source will improve things later. It's not really that important to me now as I intend mostly to work in Unity and on that front I've watched mobile HW & SW make giant strides in 3 years with regards to Unity and rendering and for very reasonable prices. AMD's opensource ProRender should have the same effect on the desktop platforms.
I'm not familiar with AMD ProRender, but I suspect it's like Iray (and other renderers), where it uses its own idea of materials. That's really where it's at. Had Daz not spent (obviously considerable) time working on Iray materials, and the ability to auto-convert 3DL materials to Iray-compatible, I don't there would have been much interest.
OT, what scripting engine do you use with Unity? I'm trying to get a sense of how many people use Unityscript over C#.
I use C#. I've a dual degree in computer science & applied mathematics for which I had to learn Assembly & C so moving onto C++, Java, & C# was the preferred choice. I've used UnityScript, Javascript, bourne, korn, csh, and other such interpreted languages quite a bit but I don't really like them. I like for the data types to be defined as unambigiously as possible.
In Unity mostly the non-programmers are using UnityScript over C# because of the large number of self-taught website tinkerers and they tend to chose Javascript as a practical language they can use rather than a backend language like Java they'd never likely have the opportunity to use or even have access to. Most early coding and game examples in Unity were also in UnityScript
It's getting more and more the case though that the new users in Unity are choosing C# over UnityScript because Unity's Learn tutorials tend to choose C# over Unityscript. C# does have the advantage of better utility outside of the Unity environment with no 'gotchyas' and lots of good introductory books written to teach it.