Fjord

[N-drju]

These are very troubled waters. Hope the skipper can survive this.

[DannyG]

Killer image maze, bit sharp looking as mentioned, still a looker

[mhaze]

Cheers -  still waiting for a large experimenta render to finish

[mhaze]

I think this is much , much better.

Rendered at 3600 x 1200 and then reduced to half that size - same .jpg compression.
I 'm rendering another with some changes to the bird populations, a simplified texture for the background rocks and .8 haze. We'll see if that adds further improvement.

[archonforest]

Rendered at 3600 x 1200 and then reduced to half that size - same .jpg compression.

Why did u do this? Is this doing something with the quality?

BTW render looks killer!

[Tangled-Universe]

That looks really good Mick

Very interesting that it worked better at high res.

Oshyan, remember I complained a couple of days ago about TG's propensity to render more high frequency details over distance?
I think this situation is also about this.

To exaggerate for the sake of this example: if I'd make a square image map of 50% grey and 101x101 pixels with the centre pixel pure white, map entire planet with it, then TG would render the terrain with noisy white specks over distance, despite that 0.01% of that texture actually *is* white.

Why does TG tend to "prioritize" the bright parts of (procedural) textures over neutral/dark parts? Especially over distance.

It's an issue and I remember when TG2 was advertised as a renderer which didn't need the TG0.9 "render huge and resize trick" anymore.
This particular render shows that it at least isn't entirely true. (it is true in other ways of course)
As a matter of fact, I do the same for my vegetation, although usually max 50% bigger as rendering vegetation already takes way too long.

Haha, this almost sounds like a rant, but isn't one. This is an issue though if you'd ask me?

[choronr]

Very good Mick, this is much better.

[Oshyan]

Hmm, interesting. The re-render *certainly* looks better, but I am seeing what I think T-U is seeing - this "crunchy" detail in the distance that doesn't seem appropriate. The foreground looks great, but the background doesn't seem to be improving as much with the downsample trick you're using. I'm curious what this looks like 1:1, i.e. at the original size.

T-U, your question would be best answered by Matt of course. I'd be interested to see some basic tests of the issue though, like you describe.

- Oshyan

[Matt]

That looks really good Mick

Very interesting that it worked better at high res.

Oshyan, remember I complained a couple of days ago about TG's propensity to render more high frequency details over distance?
I think this situation is also about this.

Isn't it just a matter of anti-aliasing? I mean in a broad sense of the word, not just TG's "anti-aliasing" parameter. To anti-alias high frequency details in the terrain you might also need to set Detail higher than 1. Usually we don't do this because of the cost, but it can make a noticeable difference. If you don't mind spending extra render time to render a higher resolution and then downsample the result, you should prefer to render higher quality at the target size instead.

To exaggerate for the sake of this example: if I'd make a square image map of 50% grey and 101x101 pixels with the centre pixel pure white, map entire planet with it, then TG would render the terrain with noisy white specks over distance, despite that 0.01% of that texture actually *is* white.

Why does TG tend to "prioritize" the bright parts of (procedural) textures over neutral/dark parts? Especially over distance.

Yes, it will produce white specks all over the place because Terragen doesn't prefilter textures, so to anti-alias this well you'd need high Detail and high AA (or just high AA if the surface is being ray traced). The example you gave is a difficult case. But it doesn't "prioritize" bright parts over dark parts. The total energy reflected should be correct, in the aggregate. It's an anti-aliasing problem. If Terragen were to prefiltering image-based textures, that would help in this case, but it can't do this for procedural textures.

It's an issue and I remember when TG2 was advertised as a renderer which didn't need the TG0.9 "render huge and resize trick" anymore.
This particular render shows that it at least isn't entirely true. (it is true in other ways of course)

We haven't seen a render at 1800px with double the detail and double the AA, so this is far from conclusive.

As a matter of fact, I do the same for my vegetation, although usually max 50% bigger as rendering vegetation already takes way too long.

It should be more efficient to do the anti-aliasing in Terragen. If this isn't the case, I'd like to see examples. What you need to do is render with a higher detail as well as higher AA, and use a high quality pixel filter. I'd usually recommend the Mitchell-Netravali filter, but perhaps the Cubic B-Spline (soft) filter might work better in some cases. Enable "anti-aliasing bloom" so that super-bright pixels don't alias badly. Another problem with downsampling a larger image that has clipped pixels is that the bright pixels can be hue-shifted and desaturated in an unrealistic way when clipped pixels are averaged with non-clipped pixels. Although if you work with EXRs and take care to soften the over-bright pixels then this isn't a problem.

Matt

[TheBadger]

^^ Hello,

Apart from the software specific and heavy tech stuff, why is the answer not the same as the answer for matte painting? What I mean is, regardless of the cause, doesn't resizing work here for the same reason it works in matt painting and photoshop painting?

I realize you guys are zeroing in on software specific cause, but I just want to be clear that the result is the same. I mean, there is no reason to talk about the resizing in different terminology from how matt painters talk about it, even though we are looking at a render and not a painting, it that correct? O,r is it different, simply because its a render and not a painting?.. Just want to be sure is all.

And then for clarity, apart from the renderers way of working, we are still just talking about pixels right?

^^

Isn't it just a matter of anti-aliasing? I mean in a broad sense of the word, not just TG's "anti-aliasing" parameter. To anti-alias high frequency details in the terrain you might also need to set Detail higher than 1. Usually we don't do this because of the cost, but it can make a noticeable difference. If you don't mind spending extra render time to render a higher resolution and then downsample the result, you should prefer to render higher quality at the target size instead.

So what would be the difference in render time (if any) between the larger resize, and the on target size higher quality? I have trouble believing that it would be equal in any example or even just a few cases. But I really never did a 1:1 test of anything... Would like to know!

[mhaze]

OK I'm going to try a render with detail set at 1 and AA at 12 the x2 image took 40hrs at detail .5 and AA 5.  There will will be diferences aas I've changed the lighting and added haze. If the render doesn't take too many years I'll also do one with the old lighting and no haze,

[mhaze]

In the meantime here's one with the new lighting, simplified distant texture haze and enviromental lighting

[mhaze]

Here's a crop of the background at 3600 x 1200

[mhaze]

Part of the problem is the texture  - two colours scaled at just the right size to cause issues!!!!  Also rendered at detail.5 aa5 there is not enough resolution to render the texture nicely. 

[choronr]

Mick, I'm seeing some nice improvements here. Your perseverance is paying off.