Planetside Software Forums

Hi guys

What do you think is causing this (see pic attached) There's numerous issues with this image but it is basically how I want it.

Firstly there are unsightly concentric "bands" in the cloud layer,
Secondly there are odd haze affects in the low fog about the flanks of the island (there is NO fog layer) and,
Thirdly there are strange "blobs" in the centre back of the island.

I have no idea why these artefacts are there but it would be great to get rid of them without changing the image too much.

Higher render and quality settings do not seem to fix these issues but rather exacerbate them.

I have removed the island and models in the attached file.

Cheers

Richard

---

Any chance you could share the clouds? Maybe easier to troubleshoot when we have more info on how the clouds are set up.. I suspect it might not be a rendering setting issue..

EDIT: oh nevermind, somehow missed the tgd file :D

Hmm.. The problem seems to disapear when you render without the atmosphere. I recall someone having this issue and lowering haze value reduced the problem, alltho not entirely removes it. I dont have time to do further testing today but it would appear it's related to the atmosphere node

Last test render with atmo sample jitter @ 1 seemed to reduce issues a lot

Hi freelancah
Yes I figured it was the atmo node but unfortunately I pretty much need those settings as they are for the "god rays".
Trying a 720x405 now and it looks promising. Atmo sample jitter is at 2 and the banding has gone as has the "fog" and "blobs"
Do you know if atmo sample jitter will have a negative effect on animation?
Cheers
Richard

I dont know. I imagine it might but cant say for sure

Quote from: cyphyr on December 17, 2011, 01:30:34 PM
Hi freelancah
Yes I figured it was the atmo node but unfortunately I pretty much need those settings as they are for the "god rays".
Trying a 720x405 now and it looks promising. Atmo sample jitter is at 2 and the banding has gone as has the "fog" and "blobs"
Do you know if atmo sample jitter will have a negative effect on animation?
Cheers
Richard

I think you can't push jitter values over 1. A jitter of 0 means 0% randomization of the samples as 1 means 100%.

If you want flicker free soft shadows you would also need to set the sample jitter to 0 for the shadows.
Same goes for reducing surface flicker by disabling jitter shading points in the render subdiv nodes.

Consequently I'd expect that a sample jitter of 0 may help reducing atmo flickering.

Ook! stuck between a rock and a hard place as they say.
Raising the sample jitter has solved the banding issue (and the odd blobs and fog) but lowering it may help with flicker in the animation.

Quote from: Tangled-Universe
If you want flicker free soft shadows you would also need to set the sample jitter to 0 for the shadows.
Same goes for reducing surface flicker by disabling jitter shading points in the render subdiv nodes.

just to note I'm NOT using soft shadows. Do you mean the tickbox by "Micro vertex jittering" and Detail jittering" in the "Extra" tab of the render node.

One issue I'm finding is that whan it comes to subtle effects like reflection, transparency and volumetric effects they do not necessarily translate well at different resolutions. What works well at 720p is challenges at 1080p.

Thanks

Richard

You may need to find a trade-off setting indeed. Increased jitter may also be a tad bit slower.

I know you're not using soft shadows, but I was only explaining 2 conditions where reducing jitter improves results for animation and translated that to the issue you're having.

There shouldn't be flicker in the atmosphere if the sample level is high enough. I've seldom seen a useful application for reducing the sample jitter.

As for soft shadows, I don't even know that reducing sample jitter to 0 there would help in animation. I think the sample points would still vary *between frames*. The better approach, as with atmosphere, is just to use sufficient sample levels to avoid noise and thus the "flicker" (which is really noise variation between frames) won't occur.

- Oshyan

Quote from the 2.2.03.1 RC changelog:

Improvements to soft shadows:
- Soft shadows now use a slightly better sample distribution to slightly reduce noise.
- Sunlight has a new option "Sample jitter". Default value is 1 which qualitatively matches the old behaviour, giving jittered stratified sampling which is statistically unbiased but produces noise. A value of 0 produces no noise, but introduces bias and stepping artefacts instead. This may be favourable in some situations, e.g. animations.
- Soft shadows of Sunlight nodes no longer flicker between frames in an animation, provided that jitter is set to 0.

Quote from: Oshyan
I think the sample points would still vary *between frames*. The better approach, as with atmosphere, is just to use sufficient sample levels to avoid noise and thus the "flicker" (which is really noise variation between frames) won't occur.

- Oshyan

The jitter creates the variation between frames ;) For every frame the jitter creates a different sample pattern and that's why you need more samples, in order to have the result converge with previous/next frames. Without jittering the sampling is more evenly distributed, but can create bias/stepping as you can see in the quote above.
You are right though that with atmosphere it's better to use jittered sampling and increase samples, as reduced jitter can result in artefacts as Richard has just shown and is also in the quote above.

Oshyan, remember the issues with the little moon shadow popping on the Saturn thing a couple of weeks ago? That's why I brought up the fact I'd neglected to lower the sample jitter in the lighting node for the .tgd, and that that would probably be part of the popping problem. I guess you missed that in one of my pm's? I'd guess that doing that would solve all the popping issues, I just assumed you'd tried it and that it hadn't fixed things.

Thanks for the detailed answers and analysis.
Looks like the solution will be HIGHLY scene dependant. If I want to keep the scene "exactly" the same I'll have to considerably up the sample cont. Not in front of the pc atm but I'll try upping the sample count tomorrow incrementally to a point where the banding is gone. This may help with some other issues I'm having with the scene (high noise in the reflections on the water). Hopefully this won't add too much to render times (I'll settle for twice as much!)

I'll be hopefully able to step back from the pc's long enough over the festive break to get some decent animations rendered.

cheers
Richard

Quote from: dandelO on December 18, 2011, 06:00:25 PM
Oshyan, remember the issues with the little moon shadow popping on the Saturn thing a couple of weeks ago? That's why I brought up the fact I'd neglected to lower the sample jitter in the lighting node for the .tgd, and that that would probably be part of the popping problem. I guess you missed that in one of my pm's? I'd guess that doing that would solve all the popping issues, I just assumed you'd tried it and that it hadn't fixed things.

Guess I must have missed that, yeah. Oh well.

Martin, it looks like you remember the change logs better than I! Good catch. I stand corrected. I tend to forget that it's not always the sampling of the element I'm thinking of (the most "obvious" element to me in a given situation) that matters. In this case it's the light being sampled (which is obvious from the jitter control of course - I should have drawn the right conclusion from that fact alone), not the terrain sampling (which does change frame to frame), that matters, and that stays the same (dependent on the jitter setting) regardless of camera movement (unless light settings change between frames of course).

- Oshyan

Erm, well I'm now confused! (not difficult I know)
The scene has rolling clouds so I guess that means the light will differ between frames.
The sample quality of the clouds has to be high to avoid noise about the edges of the cast light beams.
The atmosphere sample quality also has to be high to show the light beams without noise.
So basically there are no "clever cheats" to get around long render times, I'll simply have to raise the detail and sample quality to a point where both the banding and noise disappear and live with the extended render times. Oh well its my own fault (as usual) for going for a scene with so many extremes! lol
Cheers again
Richard

Hmm ok I've upped the atmo samples to 56 (with RTA ON) and the noise is pretty much gone but not entirely. I'll let the render complete and upload the result.
I'm wondering if this may be a case for having RTA OFF.
Richard

I'd say yes...

In my experience (quite extensive in the meantime) I figured that RTA is fast when using AA levels of ~4.
Above that it gets lots slower than without RTA.

In my latest work, still a WIP, I had a quadruple increase in rendertime when rendering RTA with AA8 and 8 atmo samples (the bottom limit the renderer accepts) versus RTA OFF and 16 atmo samples.

Hi Richard,

The banding and blobs are caused by an incorrect setting for sample jitter in the atmosphere or in the clouds. You should usually set sample jitter to 1. There may be some cases where you can reduce the jitter if nothing 'interesting' is happening in the atmosphere but I don't think they are common.

Matt

RTA enabled is only going to be slower for the desired results *if* noise is acceptable at lower sample levels. RTA can generally give you higher quality at equivalent or lower render times. I would guess the main reason for the render time issue in your case T-U is that you can't set the sampling for atmo lower than 8, and it's probably a daytime scene where you could get away with a lot less. Disabling RTA when using higher AA can definitely make sense, but again only if your clouds and atmosphere stay noise free with equivalent or lesser render time overall. In Richard's case where noise is still a problem *and* RTA is being used, even with high atmo settings, I suspect using higher AA will not be a problem - turning off RTA would likely just result in even more noise.

- Oshyan

Quote from: Oshyan on December 20, 2011, 01:20:50 AM
RTA enabled is only going to be slower for the desired results *if* noise is acceptable at lower sample levels. RTA can generally give you higher quality at equivalent or lower render times. I would guess the main reason for the render time issue in your case T-U is that you can't set the sampling for atmo lower than 8, and it's probably a daytime scene where you could get away with a lot less. Disabling RTA when using higher AA can definitely make sense, but again only if your clouds and atmosphere stay noise free with equivalent or lesser render time overall. In Richard's case where noise is still a problem *and* RTA is being used, even with high atmo settings, I suspect using higher AA will not be a problem - turning off RTA would likely just result in even more noise.

- Oshyan

I don't wanna be a bitch Oshyan but I think I don't agree with that :)

You have seen my Dutch Landscape WIP which has a plain sky at dusk with clouds in the far background.
With that WIP I had 4x longer rendertimes when using RTA with AA8 versus RTA OFF and 16 atmo samples.
As you said this has a rather simple sky and it may not need many samples with AA8, likely lower than 8, which is technically not possible atm.
So in that case I can see your point.

However, the scene Frank and I are working on, crater lake, has the same. We use 4 or 5 cloud layers there and it's ~2-3 times faster to render it without RTA since we use AA8 here as well.

I think there's more to it, perhaps need to make a thorough test some time.

I think the main difference between our scenes is the "thickness" of the atmosphere. In other words the haze density.
In order to see the volumetric light rays I have had to raise the density to 5 (I could play about with this but there are just so many permutations I'd like to keep one part constant!).
I have not seen "Crater Lake" wip but from memory your Dutch landscape had quite a clear atmosphere, ie a lower haze density. I think it is this density that causes my longer reder times due to the increased noise. I tried with RTA OFF and the frame was about half way through after 2.5 hours, the quality was not great either. I don't mind a "little" noise as Nuke has a node to remove noise and flicker that is surprisingly effective.
Cheers
Richard

Ah I see, good to know, thanks :)

Quote from: Tangled-Universe on December 19, 2011, 09:45:44 AM
8 atmo samples (the bottom limit the renderer accepts)

The lowest number the renderer accepts here is 1.

I seem to recall values lower than 8 in the atmo node resulted in some render issues though. Have to test again I guess.

T-U, tuning RTA settings can be tricky sometimes, but I've seldom seen it result in across-the-board longer render times unless it's in a situation where, as I said, you simply can't lower the sample/quality settings enough to compensate for the high AA level (i.e. a simple atmosphere situation). I'd be curious to see your scene and try a few things myself thoughg. Even if the render times were higher with RTA, 2-3 times faster without seems like a *lot*. Any chance you could share the scene? ;D

- Oshyan

Quote from: Matt on December 21, 2011, 02:35:00 PM

Quote from: Tangled-Universe on December 19, 2011, 09:45:44 AM
8 atmo samples (the bottom limit the renderer accepts)

The lowest number the renderer accepts here is 1.

Since when is that? I tried that some times and below 8 the atmosphere turns entirely gray (I believe, at least something happened which indicated 8 is the limit).

By the way, if you replied to what I said literally then you're always right since TG2 doesn't prevent me from entering a value lower than 8 :)

Quote from: Oshyan on December 21, 2011, 07:06:41 PM
I seem to recall values lower than 8 in the atmo node resulted in some render issues though. Have to test again I guess.

T-U, tuning RTA settings can be tricky sometimes, but I've seldom seen it result in across-the-board longer render times unless it's in a situation where, as I said, you simply can't lower the sample/quality settings enough to compensate for the high AA level (i.e. a simple atmosphere situation). I'd be curious to see your scene and try a few things myself thoughg. Even if the render times were higher with RTA, 2-3 times faster without seems like a *lot*. Any chance you could share the scene? ;D

- Oshyan

That may be the issue indeed. Frank created the cloudsystem in that work. I'm pretty sure he's fine with having you do tests with it, but I'll doublecheck and will send it out to you :) Interesting stuff :)

Cheers,
Martin

@T-U,

The main issue I'm aware of with low samples in the atmosphere is noticeable transitions between different levels of noise. The actual number of samples increases as you look through longer paths in the atmosphere, changing the amount of noise. If noise levels are low enough (e.g. with ray-trace atmosphere enabled and high anti-aliasing), you probably won't see these transitions. I haven't seen the grey atmosphere problem.

Thanks Matt,

I can reproduce the behaviour you described when I'm not using RTA with <8 atmo samples.
I suspect somewhere in the meantime something has changed as I can't get the artefacts reproduced anymore.
It's good to know, and to see, that I can render with RTA and 1 or 2 atmo samples.

However, as I will soon show, this has very little impact on rendertime.

Oshyan, I have devised some tests which I need to put in a table-like sheet to present clearly.
I'm sure you'll find the results interesting :)

Here's test 1:

At the top centre is the benchmark which has been rendered without RTA and with 24 atmo and 220 cloud samples which is equivalent to a detail setting of 0.76.
I then tested with 4 different atmo sample settings and 3 different cloud sample settings, all with RTA enabled.
The AA setting was 4 for all tests.

My conclusion in regard to atmosphere:

In this particular test adding more cloud samples did increase rendertime just slightly for all 3 cloud sample settings.
So, lowering atmosphere samples to <8 with RTA enabled does not change rendertimes dramatically.
This fits perfectly with my observation I told here before where my image with RTA @ AA8 and 8 atmo samples rendered 4 times faster when without RTA and 24 atmo samples.

My conclusion in regard to clouds:

In this particular test the noise levels are visible at the bottom left and right of the clouds.
When comparing the RTA OFF vs RTA ON conditions you'll notice that @ roughly 100 samples the result is similar, regardless of atmosphere samples.
However, rendertimes are ~2x longer.
Rendering with 40 atmosphere samples gives worse results and not much improvement in regard to rendertime.

Combined conclusion:

Rendering with RTA at similarly resulting noise levels is ~2x slower.
Rendering with RTA with more resulting noise is a little bit faster.
As discussed before, reducing atmosphere sample levels below 8 is not the cause for slow rendertimes with RTA.

So I will not advocate for RTA here anymore ;) and especially not when using AA>4, since that gives even bigger discrepancies as I explained before.
Due to the exponential sampling nature of AA this makes sense to me.

One can of course argue about the test setup, but so far these findings fit with what I've recently been experiencing. (after some discussions with Frank who mentioned it first to me that RTA isn't faster.)

Cheers,
Martin

---

Interesting results indeed! I've benchmarked quite a lot of scenes showing a marked improvement in speed/quality with RTA (which I will now go and verify ;D). So it must be scene-dependent, which is certainly possible. This is why I asked for the scene you were working with so I can see if there's anything else going on. It would definitely be good to get a more comprehensive picture of how all this works in practical scenes.

- Oshyan

I'll show you another example...it's a crop from my Dutch Landscape WIP you know about...I will render it now using 32 atmo samples and 32 cloud samples (det 0.82) with AA8 and detail 0.8 and GI 1/2/6 in the renderer. I'll compare it with RTA @ AA8 with 1 atmo sample and 4 cloud samples.

In my previous test AA4 allowed for a 2-fold reduction of cloud samples and since AA8 is 4 times "better" than AA4 ((8x8)/(4x4)=2) I estimate an 8-fold reduction of cloud samples should be ok.

Here it is...
Notice the slight slight slightly more noisy atmosphere, but especially notice the quite different looking clouds!
Rendering it now with RTA and 2 atmo samples + 8 cloud samples...see what it takes to make it look as good as RTA OFF :)

When it comes to practical examples I think it can't get any closer than this.
It's a difficult lighting situation, requiring good sample settings and it has objects which justify using high AA levels and thus even more carefully chosen sample levels for atmosphere/clouds. As this test shows AA8 doesn't offer extreme reduction in samples as it is already slower and inferior in regards of cloud-rendering.

This fits with the previous example which showed atmosphere rendering comes cheap and clouds don't...

---

Getting closer with 2 atmo samples and 8 cloud samples...took exactly 18 minutes:

---

Last one...now with 12 cloud samples and still 2 atmo samples...
It turns out I have been lucky with the 1 and 2 atmo samples, since this "seed" shows I was short on atmo samples.
Clouds are nearly the same, but rendertime was 32m37s.

Logically I won't push this further...I think/hope the examples are clear enough.

Cheers,
Martin

---

I guess I'll have to wait until my own re-tests are finished to comment with anything useful. All I know is in the past my findings have been different than what you show, so it's very surprising to me. Definitely worth more investigation.

- Oshyan

Well, I'm a bit surprised too since I too remember we tested some stuff together "in the beginning"...at least we discussed in detail how this would be benificial and how the approach should be, for hours even :)
Nonetheless it turns out that it somehow doesn't hold, but frankly I don't understand why this happens now.
Not that I think it has to do with changes in TG2, but the only reason I can think of is that we tested it too artificial and not enough in practical situations. Perhaps.