Do lights and reflective surfaces slow down renders, if they not in view?
background
Posts: 820
Do lights and reflective surfaces slow down renders, if they not in view?
I know if I have lights or reflective surfaces which are in the same 'room' but not in the camera view then they still need to be considered by Iray because they might be seen in reflections etc. What about lights and mirrors in a seperate room of the scene though? There is no way light/reflections can affect the render because there are closed doors and walls between them and the camera, but I am wondering if they slow down the render anyway, just by being part of the model. Will I save render time by setting lights and mirrors 'invisible' if I know they cannot affect the current render?
I guess it very much depends on how Iray handles light rays.. If rays are only calcuated from the camera lens outward , then having a light in another room, or inside a closed box, shouldn't affect the processing because the light rays which enter the camera can never get to the light source. I know on reflections it is possible to set the max number of bounces.
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
© 2026 Daz Productions Inc. All Rights Reserved.
Comments
I am aware that, even in another room, a light could be visible if, for example, an intervening door has a glass window in it.
Light rays in Iray do indeed start at the camera, then bounce until they either find a light source or reach a coded limit on the number of bounces.
This sounds counter-intuitive to many, because, hey, light goes the *other* way, but it's more efficient to do it this way; when you look at all possible light paths within the scene, the light paths that end at one camera with a limited field of view is a much smaller set of paths than alll the light rays that start at many lights (and may radiate in all directions), and thus fewer processing cycles are wasted on light that goes nowhere.
Doing it this way means that, for the most part, surfaces and lights a ray path is never likely to intersect have a relatively minimal impact on the speed of a render. Indeed, contrary to what many people say, adding more lights to an Iray render makes it *faster*, as it means a ray is more likely to intersect with a light source in fewer bounces.
There's a little bit of overhead from loading stuff that is irrelevant to the render, but unless it pushes you over a VRAM threshold, it's unlikely to have a noticeable impact on render speed.
Thanks Matt, I'm happy that's how it works, otherwise I would probably waste more time going through the whole model and turning off irrelevant lights and mirrors, plus I then have to remember to turn them back on, and I'm sure to set off a later render and 'then' realise I didn't turn something on, that should be in shot.
I'm afraid that the proffered explanation is correct on the surface, that light is modeled from the camera to a light source, but it is otherwise very, very wrong.
Yes, light is modeled from camera to light source because in order to produce an image, it must have at least one ray that passes through each and every pixel on the camera's focal plane. Otherwise, the image could have "holes" in it that never received a single ray. So initially there is a ray for every pixel in the output image that emerges from the camera and pass through each pixel in the camera's focal plane (that represents the output image) and then branches into additional rays as it interacts with surfaces in the scene according to the physical laws governing the behavior of light, i.e. reflection, refraction, reflection, absorption. If it did it the other way around, there would be no guarantee that there would be a value for every pixel. When you see Iray counting, it is adding up all the resultant rays that eminated from a given pixel and averages them to determine the final value for that pixel.
And this is where the above descriptions errs badly: The probability of these rays actually hitting a light source is close to zero. So a probabilistic model is used to determine a light source's influence on the ray, and this is done for every light source in the scene, regardless of whether it is inside the camera's view frustrum. You may have heard the term "Indirect lighting". For example, if it's a point light, the cosine of the angle between the ray and the light is used because that's a measure of how directly the ray hits the light source. The ray does not have to actually hit a light source because it probably never would anyway.
Rays do not stop at their first interaction with a light source. Like the previous explanation suggests, they keep going until the configured limit, but they interact with all the light sources they encounter, with each light receiving a "weight" determining the strength of its contribution to the final pixel. Again this is because for, say, a point light, the probability of a ray passing through the scene actually passing through a given point is effectively zero and so a probabilistic model is used, and this model averages the affect over all the lights. It may seem to stop at the first light source because the effect of a single light source can sometimes overwhelm all the others, for example an area light that the ray does actually hit will be modeled to overwhelm a point light that the ray passed at a great angle.
So, the number of lights influences the number of samples necessary to achieve realism. The materials determine how many rays will be created for each pixel because of its physical properties.
I'd suggest reading the summary of a research paper on light transports instead of asking here; you're likely to get answers more aligned with facts rather than someone's intuition that seems correct but is actually quite wrong. You don't have to read the whole paper; the summary is often written to pique the interest of readers with the assumption that they don't understand the paper's content because they haven't decided to read the whole paper yet :)
Or, rather than taking that tone, you could more correctly assume that I was simplifying for the sake of not providing a long and technical explanation.
I've tested this in *ridiculously* extreme circumstances. I've rendered scenes twice; once with just the lights that could affect the camera view, and again with many hundreds of times as many lights again added, but sealed away out of view. The only difference in the final renders was at the level of random image noise of maybe one or two bits (so the extra lights were, indeed, having no effect on the result), but even under a completely over the top scenario where I'd increased the number of lights in the scene by multiple orders of magnitude, the difference in render time was a few percent.
At the level most forum patrons need to understand it, there is no meaningful difference in the render times.
Thanks guys. I think for my purposes, and bearing in mind the time and organisation would take me to activate and deactivate lights, I'm happy to go with Matt's suggestion, although I accept 'The Mystery Is The Point's opinion that there may be some technical downsides to leaving unseen lights on. I don't want to start an argument, life's too short and there are far more important things in the world than a few milliseconds unneeded calculations.
I don't believe I took any particular tone. I just responded to statements that are objectively not true with statements that are. I think there is something wrong with what you call "simplification" if it results in statements that are objectively not true.
The problem I had with your assessment is that the OP might generalize what you wrote to think that the number of lights does not affect render time at all, ever. If there had been some transmissability on the materials on the objects separating the other lights from the camera, those lights might start to matter. Better to not assume the OP is incapable of understanding anything but the simplest explanation, simplified to the point of being incorrect even, and rather arm him with an explanation given to the appropriate depth to actually understand the general principal and successfuly apply it to his own questions in the future. If the OP didn't understand it, they can say so, or in any case, an incorrect explanation is actually worse than abject ignorance.
@background TL;DR - It won't all be applicable, but a really interesting peek into how physically based light transports of all kinds work is in this. Worth the money to really understand our common hobby.
Please keep the exchanges civil, without pointedness.
At the extremes, the testing I did multiplied the number of lights up by a factor of 256, and yet resulted in a difference of, at the most, about 5%. That's a nigh-unthinkable number of lights to have 'out of sight' unless someone is trying to break things like I was, yet the final result is barely noticeable within the kinds of statistical variation you would typically expect in hardware benchmarks.
We are genuinely talking about a case that you would find so much longer finding and deleting/hiding the correct lights than you would save on the render. That is false economy.
My statement that "unless it pushes you over a VRAM threshold, it's unlikely to have a noticeable impact on render speed" is accurate for almost everyone under almost every circumstance. Sure, there's some hypothetical nigh-infinitesimally-unlikely scenarios in which someone could spend less time deleting lights than than they save on their render, but that hardly merits what I said being described as "very very wrong".
Does anyone know what would cause a (very) basic indoor scene to bring rendering speed to a crawl? I already tried the obvious stuff such as maximum ray bounce, and even got to the point of seeing the effect of too little bounce, so it's definitely not that.
It's usually stuff like reflection and refraction that is the killer, but there's none of that in the scene, and it's not even fully enclosed.
I'd check your log file. It might be reporting that you've fallen back to CPU (which can happen even with a simple seeming scene, such as if something in the scene has got set to a ridiculous SubD level and caused the geometry load to exceed VRAM).
Other than that, it's hard to say without knowing more specifically what's in the scene.
@Matt_Castle - As someone with a very low ability to absorb technical Daz info (at least at this point in my journey), I greatly appreciate your explanation -- both the original one and of the renders experiments you've done. Thanks for taking the time to give it in a form those of us on the beginner end of things can understand
I have no choice but to render on CPU at the moment, but I think I found the problem. It seems the physical size of the scene plays a large part since the only notable difference is the size, not the complexity. What's odd is that if I use the Geometry Editor to trim-off the parts not being rendered, it doesn't really change anything, not a notable amount anyway.
It was only cheap, but I bought a bunch of them from the same series which in total, wasn't. Still I've only downloaded two so far, so I'll just have to request a refund before downloading the others. I suspect the problem will be the same across the rest in the series, and I get the feeling it could be a side-effect of CPU rendering.
Thanks for the suggestion by the way. I thought you'd hit it right on the head at first because I had indeed been playing around with subdivision prior to downloading.
In which direction did the size differ? Anythng which increased the number of bounces on each path would slow rendering, so more reflective or brighter surfaces but a small room might too, if the power of the ray was attenuating with distance.
@Richard
Looking from above, the X axis is by far the largest, but the entire scene is way larger than anything I ever touched before. Using Blender as an example, the scale feels completely irrelevant because regardless of whether you model in millimeters, centimeters or even meters, rendering the model makes no difference to the render speed because it has no real, fixed measurement. You can can quite happily model in meters and then change the unit to millimeters and the render time will not be effected. I thought that iRay would handle Daz Studio units (or whatever it is they're called) in the same sort of way, but since trimming stuff off using the Geometry Editor doesn't appear to effect it, I suspect it's handled somewhat differently to the way Blender does it.
By the way I hope you don't mind me asking, but while I have your attention will you please check my message in the Premier thread. I was desparately wanting to try something TimberWolf suggested, but I'm worried if I try installing a different version of Daz Studio on this same Linux install, it might screw things up. It's really just about the (new) way they implemented the Hair Editor in the new version of Daz Studio, it poses two questions for me, those being:
1 - Is the Hair system now part of the viewport in the free version of the new Daz Studio, or is it implemented that way only for the Premier version?
2 - If included in the free version, are we able to comb store-purchased strand-based hair in the viewport, or does it only allow combing of home-made hair?
Size of the geometry shouldn't matter compared to the size of the textures competing to fit into VRAM.
Well, putting the pig-latin technical jargon to one side for a moment, I had the same problem but was able to vastly imporve rendertimes by investing in a studio utility that hides all surfaces not visble to the camera and, when doing indoor scenes, switching the render settings from scene and dome to scene only. Unless I'm using HDRI to light a scene but I generally only use HDRI for images set outside.
Going too deep into the technical side of studio tends to end up sucking all the joy out of creating images in the first place. There are penty of tutorials on using iray - both free and for purchase - which explan how to use it effectively without overloading you with a mass of tech details.
That's a very different circumstance to the one that was being discussed. The initial question was about parts of the scene where there is no (reasonable) light-path to what the camera can see, in which case
If you hide everything that's outside the cone of the camera, then yes, it will significantly speed up the render, because rays will likely quickly bounce out of the scene and get terminated. However, this will noticably affect what's rendered, because it's a ray-traced render. When ray-tracing, it's not only possible but almost certain that objects near but outside the view can be reflecting (or blocking) light into the view, or they can show up in reflections (most obviously in sharp specular reflections like a mirror, but it can also very noticably impact diffuse reflections).
Indeed, for the reasons, I do not personally like any tools that automatically cull objects outside the view. I deliberately put objects into scenes that are entirely out of the camera view, because the shadows, light and reflections from them - even if they can't be directly seen - are often extremely important to getting the scene to look right.
For an example, when I was building this scene, I had to spend a large amount of time building far more of the valley than you directly see, because I was about to plonk a very reflective locomotive in it, so it would have been blatantly obvious if the world ended just out of view.
However, even with a less specular object, ultimately all light we see outside of directly staring into a light source is a reflection (or, being pedantic, a transmission, refraction, diffraction, etc - although I'm not sure that Iray, at least in its DS implementation, can actually handle diffraction), it's just often diffuse enough that we can't make out details in it.
Matt, I had to look twice to realise that isn't a photo, it's extremely convincing ( tallest character apart ). Got to love a 57xx, although I prefer the 1930's livery myself. ( the full 'Great Western' not the roundel. I think the roundel looks great on linen, and posters, but somehow looks lost on the side of a loco or tender. ).
That looks just like the station at Keighley & Worth Valley Railway
I'm not sure that size, in physical units, is the issue - were there more shiny/shinier surfaces in the one than the other? Picking up on earlier coments, did the smaller, faster scene have more openings with nothing beyond them? Texture sizes may have been a factor too, as may material complexity.
There are no diffreences to the hair in Premier, and no you cannot edit dForce haiir with the Strand based Hair Editor I'm afraid.
Matt, Barbult and SilverGirl are pretty damn good at lighting scenes in what I personally term as a "Clearlight" way.
Oops, sorry Richard, missed your post!
Looking at the product page it does unfortunately seem as if texture size could be to blame, or at least to a large extent. I hadn't even noticed that when I bought them but they're 8K textures. Even so, since the scenes are relatively basic it's not as if lots of them are needed. In the end I decided to request a refund since I bought a set of them and together they cost a bit too much to leave unused.
I can always re-buy if and when another sale is on (once I have a more suitable system), but theres's just no way I can use them at that sort of drop in performance.
That aside, why do I feel like people are trying to hide something from me over the hair thing? Please let me know about the hair thing. You must know about it since they surely supply you with every version of Daz Studio due to you being big-time mod and all that :-D
@Richard
Sorry, crossposted again and just saw your edit. That's good news in some ways but a huge bummer in others.
Thanks for the confirmation though, it's much appreciated.
Well, that's disappointing, because I was trying to make it look like Highley Station at the Severn Valley Railway.
Admittedly, the awning is too long and I forgot to put in the foot crossing, but it's bashed out of DryJack's stuff (over at the other store), and while the buildings he's got are GWR style, they're not this specific station. So everything like the track layout is me trying to fit track props to at least roughly align over a screenshot I took from Google Earth, and things like the station building are actually a couple of different buildings of his that have been intersected to look about right.
Interestingly, DryJack's 57xx model is of 5764, in the GWR livery, and that is a locomotive that is preserved on the SVR, but as far as the timeline, 5764 was out of service at the time of my setting (which is an alternate 2018), while its sister locomotive 7714 was in service at the time*, so I did some modelling and texture work to convert it into something broadly accurate to 7714 as of the time (Which has riveted saddle tanks, and a BR number and shed code)
*And still is, in fact. I was at the SVR's Spring Steam Gala the weekend before last, and I saw the timetable would have 7714 taking charge of full-length trains over the full line (a relative rarity at their galas, where the smaller locos usually get allocated to small trains running only part of the line). So, while yes, "Duke of Gloucester" was the big visiting star of the show, it's also an absolute monster that wasn't going to have to work very hard on a low-speed branchline. So yes, I did make some time to see the Duke, but obviously the little dime-a-dozen pannier tank was going to have to give the climb of Eardington bank way more beans.
I rendered on CPU-only for the first 4 years I had Daz. If you're going to be doing that for 'some time' then either follow the advice of @FJM1977 and use Gimp, or other graphics software, to reduce texture size, or - if you don't already have it - invest in SceneOptimizer (which can be faster at that same thing, depending on the number of models/textures in your scenes and, I find, makes it easier to be selective on which models... like almost anything reasonably distant from the camera).
@FMJ1977 and @kpr
I wasn't aware of the utility, but I already did consider editing the texture sizes in GIMP. I chose not to get into that since I only purchased the products in question due to the offer that was on (which was seriously good), and having an interest in the subject of what they were.
In the end I chose not to download the rest, and instead requested a refund.
I think it was a bit more than just texture size. I'm absolutely convinced that scale had something to do with it but I'm just too pre-occupied with Linux and other things right now to even bother trying to fix content that I'm not that bothered about anyway. The content itself was superb, which is why you've not seen me mention the name since I didn't want my question to put people off' the product.
But it's not that big of a deal, I was just shocked at the performance drop considering how minimalistic it was.