Pixel gaps in rendering

Started by sboerner, March 22, 2024, 07:48:09 PM

Previous topic - Next topic

sboerner

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.


Doug

it looks like the small icon of an old fashion telephone
someone is trying to call you

the wide shot is a great picture

Dune

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.

sboerner

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.

Dune

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.

sboerner

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. 




Dune

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!

sboerner

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.

sboerner

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.

:(

Tangled-Universe

Intriguing issue, but annoying for you for sure.

If you like, can you share an .exr which exhibits this behaviour?

pokoy

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.

sboerner


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! 

cyphyr

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.
www.richardfraservfx.com
https://www.facebook.com/RichardFraserVFX/
/|\

Ryzen 9 5950X OC@4Ghz, 64Gb (TG4 benchmark 4:13)

sboerner


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 model


The 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.


sboerner

For some reason one of the attachments didn't make it. Here it is.