Traces in the rendered image

Hi list,
The images I rendered are not so smooth as the ones in the literature. There exists plenty of black dots and traces in the following picture. What’s the reason for the occurence of them? I guess the low resolution of Klems BSDF is related to this phnomenon. Will these significant traces influence the glare analysis by evalglare? Though the quality of the rendered image relys on several parameters, to speed up the annual simulation, the value of “ab” and “ad” is not so high. Is there any other method to decrease or avoid those traces? Besides, the simulation speed should be acceptable. Any advice is appreciated!

Hi Lee (?),

to comment on the picture, it would be good to know

  • the “not so high” values that you picked, in particular for -ad,
  • what the BSDF represents,
  • under what conditions this is rendered (sunny, clear sky?), and
  • if the ambient cache was disabled (-aa 0).

My assumption is that the ambient cache was disabled. An indicator for this is the fine-grained “pixel-noise”, that would have been smeared out by the cache’s interpolation. The noise is then an expected artefact when you sample the BSDF at inadequately low resolution. Please try to increase -ad and see if this solves the issue.

Further interpretation requires more information about the model and rendering parameters.

Best, Lars.

Hi @Lars_Grobe ,
The value of ab is 6 and ad is 1024 in the five-phase method that I adopted.
The klems BSDF of the window from the software WINDOW is served as the transmission matrix.
The image is rendered under some specific hour of the TMY weather file, and aa is not set or involved. For example, some command is as follows:

vwrays -vf south.vf -x 400 -y 400 -pj 0.7 -c 9 -ff | rfluxmtx -v -ffc \
`vwrays -vf south.vf -x 400 -y 400 -d` -o $vmtxhdr/%03d.hdr -ab 6 -ad 1024 \
-lw 9.77e-4 -c 9 -n 24 - glazingvmtx.rad -i room3ph.oct

I once set ad as 65536 for the view matrix and 10210 for the daylight matrix and there was less fine-grained “pixel-noise”. However, the simulation time was too long to obtain the image.

Hi Lee,

rfluxmtx always disables the ambient cache. Do you use a Tregenza sky model, or a refined one?

Best, Lars.

Hi @Lars_Grobe,
The direct and diffuse radiation of TMY weather file is imported to the Perez sky model. The sky division is decided by " MF:4 " with 2305 sky patches.

So is there any solution to this problem?

Hi Lee,
since you increased the sky resolution (or decrised the size per sky patch) by a factor 16 compared to the Tregenza basis that is commonly assumed for the 3PM, you should increase -ad accordingly. So I would try e.g. -ad 16384 for a start.
Best, Lars.

Hi @Lars_Grobe,
Why ad should be increased accordingly when the sky resoution gets high?

And how this value 16384 is acquired?

So higher sky resolution and ad are helpful to solve this problem of rfluxmtx?
But high value of ad will cost too much time for annual simulation. Any other method to avoid the “pixel-noise” ?