I run into this from time to time. I'm not sure what to call them -- I've tried various search terms to see if there has been any mention in the forum. Can't find any.
They're not really artifacts, just missing sections that the renderer seems to partially process and then skip over. In this particular instance I restarted Terragen to give it a clean slate, and started the render again. These patches were eliminated but another one appeared in a different part of the rendering.
This has happened before, but rarely. And this is just a still image so easy to fix by rendering the affected sections again, or (quicker) cloning in Photoshop.
Has anyone else run across these? What are they?
Edit: Using the path tracer. I've never seen them with the standard renderer.
it looks like the small icon of an old fashion telephone
someone is trying to call you
the wide shot is a great picture
I can't help you here; never had these and I wouldn't know what could be blamed. Must be something in the renderer itself, I'd say, not any setting. Nice trees in the background by the way.
I'm hoping someone from Planetside might see this and let me know what these are. I wonder if they might indicate a hardware problem, though I've run across them on two very different systems. I'm running a memory check now on the system that I used to render this, just to see.
And thanks re: the trees. This is the top part of a new scene I'm working on. Once I have something more presentable I might post it here. I'm testing a new way to create historically accurate landscapes . . . seems promising. As far as the forest goes, it's still too tidy. Needs some windfalls and dead trees, more undergrowth.
They will see it, and respond. Perhaps (if it takes too long) state the same question at the discord forum.
Looking forward to see anything you're working on, always a treat! And knowing more about your new way, if you care to share.
OK, I think I've found the problem and it's strange. ::)
But first, it's important to know that these invaders (which is what I'm calling them -- they remind me of old Space Invaders sprites) didn't appear until the foliage was added to the scene. Then they showed up in every render, but in different locations each time. Sometimes over foliage, sometimes over water or elsewhere. (I even rendered the same file on both machines last night and yep, they showed up in both.)
While loading the file I finally noticed this error. It was getting thrown each time TG attempted to load a displacement file associated with one of the trees:
FreeImage error: Warning: loading color model R as Y color model
So I looked at the file, which came with a Megascans bark shader. It was an EXR file and had a single channel (which appears in Photoshop's layers panel) named "[R]". All other EXR files in the scene have a single channel named "RGB".
FreeImage must be the library module that TG uses for EXR support. This page explains the problem: https://sourceforge.net/p/freeimage/bugs/283/. More detail here: https://github.com/imageio/imageio/issues/356.
Anyway. I just changed the channel name in Photoshop from "[R]" to "RGB" and resaved it. The error went away and (fingers crossed) the render currently running looks fine so far. Why this would have anything to do with the renderer is beyond me. But the problem seems to be fixed: No more invaders. I'll be doing nightly renderings so if it hasn't been fixed, it will show up again soon enough.
That is very weird indeed, something you'd never think of (not me anyway, never use EXR). I'm curious what staff will say about the rendering itself, if they know.
Especially good that you found the culprit by yourself!
I'm curious, too. In the meantime, last night's rendering came out fine. Running another one today while I work on other projects. If I can get 3-4 renderings in a row without the artifacts, I'll be satisfied that it's fixed.
I use EXR files a lot: For VDMs, displacements and sometimes even for masks, especially if they are paired with color adjustment shaders for choke/spread control. I just like the headroom, and displacements look way better. If you compress them the file sizes are manageable.
They're back. I thought last night's results might be too good to be true. One artifact has appeared so far in the rendering I started this morning.
The FreeImage bug is real, anyway. Good to know that. As far as the Space Invaders go, I'll wait to see if anyone from Planetside pops in here. If not I'll contact them by email.
:(
Intriguing issue, but annoying for you for sure.
If you like, can you share an .exr which exhibits this behaviour?
This could an image filter problem where a sharpening filter produces negative pixel values. Try using the Cubic B-Spline filter, it might help.
Also, are you using any of the Post Effects? If so, they might not clamp values below zero produced by image sharpening and result in strange artifacts.
In any case, using a soft filter might help to sort this out.
QuoteIf you like, can you share an .exr which exhibits this behaviour?
Hi Martin -- The EXR file is a commercial file from Megascans . . . but I bet it wouldn't be hard to make a generic file that would trigger the error. Now, I think the error is benign (or it simply cancels any displacement or bump). At any rate it's probably not related to the artifacts as I first thought. But let me get back to you.
QuoteThis could an image filter problem where a sharpening filter produces negative pixel values. Try using the Cubic B-Spline filter, it might help.
Pokoy -- This makes sense. I can see how a filter might be the culprit. I've always used Mitchell-Netravali.
For post effects, Soft Clip Effect, Compensate Soft Clip, and Contrast (0.25) are all enabled. I believe these are the default settings. (Up until recently I always rendered straight to EXR and did not worry about the Tonemap tab. But I've started rendering to 16-bit TIFF because they import very nicely into Lightroom. So now, it seems, these settings are applied.)
It's probably best to try one thing at a time. I'll start by setting the filter to Cubic B-Spline.
Thanks!
I have access to most of the Mega Scan Library, if you post (or private pm) the file I can almost certainly re-create it without you having to share the commercial file.
Alternatively, try to convert the exr to a 16bit tiff and see if the issue remains. I doubt the image would look any different after the conversion.
QuoteI have access to most of the Mega Scan Library, if you post (or private pm) the file I can almost certainly re-create it without you having to share the commercial file.
Alternatively, try to convert the exr to a 16bit tiff and see if the issue remains. I doubt the image would look any different after the conversion.
The material causing the error is "pine_2x2m_Bark_Pine_vmbibe2g." The displacement file is "vmbibe2g_4K_Displacement.exr."
I checked other Megascans surface materials, though, and found that many of them use "[R]" single-channel EXR files for displacement. They are easy to spot in Adobe Bridge -- the thumbnail previews show up bright red.
Opening and simply resaving the files (as OpenEXR) in Photoshop converts them to RGB files and fixes the problem.
The attached tgd will show the error. I've removed the displacement file from the Project_Assets folder -- you'll need to drop it in there. Here's what I see when I open the tgd:
trImage attempting to read file Project_Assets/vmbibe2g_4K_Displacement.exr
FreeImage error: Warning: loading color model R as Y color modelThe error appears benign in that it doesn't cause any rendering problems . . . but as I suspected no displacement or bump is produced. The attached renderings show the results of using the original EXR file vs. one fixed by a round trip through Photoshop.
Interesting.
For some reason one of the attachments didn't make it. Here it is.
Oh, and by the way. Changing the filter to Cubic B-Spline seems to have fixed the artifact issue. I did 3-4 renderings with no changes to any other settings, and they all look good.
One artifact did appear after I specified a custom value for the subdivision cache. But the documentation clearly warns that reserving too much memory for the cache can cause rendering issues. I'll back off on that to see if it fixes it. There is a lot of shallow water in the scene, so increasing the cache can make a big difference in rendering times.
Never would have though a filter could have 'caused' it, or at least could heal it.
I've almost always had similar problems with sun producing pixel artifacts similar to these, and the only solution was to switch to a non-sharpening filter.
My guess is that the places where the artifacts appear are super bright pixels produced by reflections of the sun and either the filter or the soft clip effect isn't error-free when it comes to HDR values.
I can understand why a filter or some other post process might product artifacts. Apparently, that is what is happening here. At least changing the filter has fixed it for now.
I also got similar artifacts when I tried to override the subdivision cache. (Just missing, black pixels, no strange patterns.) I've disabled the override and they too seem to have gone away.
One puzzling thing about the artifacts is that they always appeared in different locations. Sometimes there was just one, other times two, three or four. So they seem independent of any geometry or surface in the scene. The only constant is that they always showed up in the first 25 percent or so of the rendering.
Memory issue? My machine has 64GB of RAM, and it passed the Windows memory test I did when this all started. And the fact that they occurred on two machines tells me the problem isn't related to hardware.
Do they also appear in say sky, or barren TG ground? It would be interesting (but work) to disable stuff per pop/object, and see if there's still anything inside them that causes the filter to do something.
That's a good idea. The artifacts did not appear until the foliage was added to the scene. There are many populations, but I've done similar scenes before, some that had much larger populations. So maybe it has something to do with a particular one.
I usually do overnight renderings anyway, so it's easy to test. I'll start by resetting the filter to Mitchel-Netravali to see if the artifacts reappear. If they do I'll start disabling the pops one at a time.
To answer your first question, they usually appear over foliage, but they've also shown up on the water surface.
Mmmm, interesting to see if something turns up.
Let me guess, the foliage where they appear is reflective? Hence my suggestion that these are bright pixels produced by reflections of the sun disk. That's why they appear randomly wherever the foliage is (same with the water surface, it's reflecting the sun). I'm pretty sure that if you make the foliage material non-reflective the artifacts will not appear.
I guess another way to test this would be to increase AA sampling, it might help to 'tame' the pixel values and not triggering whatever the filter is going crazy with when too high luminosity values occur.
Ultimately, it's a long standing issue (my report of this problem is probably 10 years old) and probably best for TG devs chime in and come up with a fix, too.
Attached a quick test I did in PS, showing how using a sharpening filter will introduce ringing with negative values in 32bpc mode. The final 'pattern' will depend on the input pixels' values and position/arrangement plus the filter's strategy.
HDR_Artifacts_Sharperning_Filter.jpg
The best solution would be to move any sharpening operation to the post-processing stage where it works on the tone mapped image... and probably switching to a less aggressive filter as the default filter to avoid users running into this problem as long as it's not fixed (which is probably never).
An update: The machine has been rending constantly for the past three days. It only takes an hour or two for the artifacts to show up, so when they did I killed the rendering, made changes, and tried again.
You may notice that I'm going to be hedging almost all my statements here: probably, likely, seems like, etc. It's all been a game of probabilities; I feel like I've been chasing shadows try to pin this down.
First, I was able to narrow down the problem to a single population. (I think.) It was a low-poly wildflower population that I copied from an old scene. On closer inspection in Blender the model itself turned out to be fine. The roughness was a little low but hardly what I would call reflective. Normals all good, etc. Removing it from the scene eliminated the artifacts for several renderings in a row. I exported it again from SpeedTree, raised the roughness to 0.8, and put it back in the scene. The artifacts returned, but fewer and not every time.
Using Cubic B-Spline, as noted before, seems to help. It's rendering now with Narrow Cubic and so far, so good. I'll try other filters to see what happens.
Turning off Anti-aliasing bloom also seems to help. I did that with the filter set to Mitchell-Netravali and it rendered fine. But I only ran it once.
I don't think it's a memory issue. I've checked with Task Manager mid-render, and there's plenty of RAM available.
I'll send a note to Planetside to see if they've every seen this before. But if changing the filter fixes it, I'm happy. Time to move on.
What pokoy writes seems very plausible. Strange that I never had this occur, and I've been rendering an awful lot since 2009. Mostly Narrow-Cubic, btw. never 16/32bit or exr anyway or tiffs for veggies, never deviated much from defaults anyway. Almost exclusively detail 0.5 and AA6, only changing pixel threshold for clouds. Just my 2 cents.
There's always PS to clone out some small dots, luckily, but for animations you wouldn't want that.
Yes, I did mean to mention that Pokoy's Photoshop test seems pretty conclusive. (Thanks for that.) Enough to convince me to stop using sharpening filters during rendering.
I am puzzled that no one else seems to have run across this. Over the years I've seen it maybe 3-4 times, and always assumed it was just a hiccup during rendering, easily fixed by re-rendering a small patch to cover it up. It must take the right combination of surface material, sun angle, filter, etc.
It would be a nightmare for animation, for sure. But simple enough to avoid.
Edit: The Narrow Cubic test turned out fine, btw. I'm making this my default filter from now on. If by chance the artifacts still turn up, I'll post something here.
Update.
I removed the population that I thought was causing the issue and left the filter set to Narrow Cubic. Everything worked fine for several days and then, bingo, another artifact. But this time I had enabled all of the render passes. I was curious to see which ones any artifacts would appear on. Answer is attached.
The main file (beauty pass) is saved out as a 16-bit tiff. Passes are all 32-bit exr. The artifact is a box with a tiny dot in the center. It appears in the beauty pass and tgRgb passes. It does not appear in the tgSurfRgb pass. Then, strangely, only the tiny dot in the center appears in the tgSurfIndirect, tgSurfIndirectDiff, and tgSurfIndirectDiffRefl passes. All other passes are clean. What this all means is beyond me, but there it is.
I've set the filter to Cubic BSpline (even though I prefer Narrow Cubic) and will use that until another artifact pops up.
Quote from: sboerner on April 11, 2024, 10:02:11 AMUpdate.
I removed the population that I thought was causing the issue and left the filter set to Narrow Cubic. Everything worked fine for several days and then, bingo, another artifact. But this time I had enabled all of the render passes. I was curious to see which ones any artifacts would appear on. Answer is attached.
The main file (beauty pass) is saved out as a 16-bit tiff. Passes are all 32-bit exr. The artifact is a box with a tiny dot in the center. It appears in the beauty pass and tgRgb passes. It does not appear in the tgSurfRgb pass. Then, strangely, only the tiny dot in the center appears in the tgSurfIndirect, tgSurfIndirectDiff, and tgSurfIndirectDiffRefl passes. All other passes are clean. What this all means is beyond me, but there it is.
I've set the filter to Cubic BSpline (even though I prefer Narrow Cubic) and will use that until another artifact pops up.
Interesting, it's probably the GI/indirect element, not reflection as I suggested. Whether it's a NaN that's not handled well by the filter or something else, at this stage only TG support can help out.