Hans -
That's surprising -- but good to know.
In my tests, I've found that oversampling the image has a major effect on reducing white spots. I've also found a default minimum AA of 1 tends to exacerbate the problem, as it seems the uber shader at 4 samples per pixel tends to introduce, rather than minimize, abrupt pixel-to-pixel transitions.
Why the difference? Well, it could be I'm not testing under real-world conditions. Cecilia's problem report started me thinking about the problem, but as I didn't have a scene handy that displayed white spots, I had to force them to appear by setting high shininess values and positioning the viewer for maximize reflections. In addition, there *is* a resolution-dependent component to the problem, and my test renders have been generally low-res. I've just started generating some higher-resolution tests, so there's a chance they may conflict with my earlier findings.
Finally, it very well could be there are multiple situations that may cause white spots, and the ones in your image result from a different sort of, well, infelicity than the ones in mine.
(Actually, that was next-to-finally.
) Finally, while there shouldn't be any difference in how SH3D performs under different OSes, there's always a chance the respective VMs vary slightly. While I doubt this is the case, the is at least one significant difference in the results we're getting: I have not been able to render any image with an antiAliasing.max greater than 4. Inevitably, my attempts end prematurely, with no error generated -- the same way they do if a scene contains an invalid model. (Actually, that's not entirely true: Earlier this morning, I did abort an attempt myself; I was running the 5.2 beta under Windows 10, attempting to render a test scene at 500 x 352 pixels with aa.min = 0 and aa.max = 5, and I cancelled the attempt after an hour of constant CPU utilization > 95% had yet to yield even a single bucket of output.) I've had similar [lack of] luck under both XP and Win10, attempting to render either my 'real' plan (currently ~270 Mb) or a test scene (~ 24 Mb) created specifically for this purpose -- so there is something about 1024 samples per pixel my PC doesn't like.(BTW, I think you'll find 5 is the largest permitted value for aa.max; that is, while larger values are accepted, SunFlow quietly sets them down to 5.)
In any case, I believe I've found sufficiently odd behavior with 4-times oversampling (that is, an anti-aliasing value of 1) to recommend it not be used. (For instance, under some circumstances, I've seen reflections present at (aa = 0) and (aa = 2) completely disappear when (aa = 1). I've also found that with (aa = 1), SH3D/SunFlow sometimes has trouble determining which side of a two-surfaced plane is active. (For example, using Sketchup create, say, a cube. Apply one texture to the outside surfaces and a different texture to the inside. Export from Sketchup and import into SH3D. When rendered with (aa.max = 1), there is a good chance the interior texture will appear on at least one side of the cube. This will not occur at any other anti-aliasing level.)
Both of these issues appear to be problems with the SunFlow engine itself -- although I guess there conceivably could be a problem with the way Emmanuel converts SH3D objects into triangle meshes. I hope to have some sample scenes available in a day or two; assuming others can duplicate my findings, and given that development and maintenance of SunFlow ended several years ago, the obvious fix/workaround would be to change SH3D's default aa.min for Q4 rendering to something else. Frankly, I find SunFlow's threshold for triggering adaptive anti-aliasing -- that is, the amount by which a pixel must differ from its neighbors to trigger aa.max over-sampling -- to be conservative enough I would argue (aa.min = 0) to be perfectly acceptable. (Again, though, I need to run more tests at higher resolutions before I'm willing to go on record as having said that.)
I've also found one instance in which SH3D appears mistakenly to render what should be two identical scenes differently, which I believe to be an unintended side-effect of Emmanuel's attempts to resolve some of the earliest reports of white spots, which at the time appeared could be linked to use of the 'uber' shader for external renders. As a result, he appears to tweak rendering settings slightly based upon time-of-day. This can result in a scene that renders one way during 'local' daylight hours looking very different when rendered with a 'night' setting -- even if nothing else in the scene has changed and none of the scene's illumination comes from the virtual sun.
In any case, though, I realize I have quite a bit more testing still ahead of me before I can state any of this with conviction. Thank you greatly for ruining my hypothesis
-- it only means we are getting closer to a solution. (Seriously, though, thanks for giving this a shot. I'm sure I'll have more to ask of you before I'm done....)Maz
