Elimination of Light Flickering in TG2 2.4

[PabloMack]

I found reading the release notes on TG 2.4 promising. Specifically, I am thinking about the "Global Illumination Caching and other options to address flicker in animations". Just last week I was showing a couple of animations to a film producer who is thinking about doing a movie about men on the moon. I brought up that I have been using Terragen and find that this package produces the most realistic landscape images of any package that I know that is on the market. I showed him the animation that I did for Oshyan's benchmark render and he immediately asked about the light flicker problem. Then I showed him a moonscape flyover animation I did that had obvious geometry popping problems. James then asked if there were any other packages on the market that produce better sequences. I then mentioned how Vue had been used in many movies but that I didn't have the package but was thinking about getting it. But I said that I thought Terragen's images looked more realistic than those produced with Vue. My thought was that, if these two problems could be eliminated, then Terragen would be a lot more desirable for commercial applications.

These two problems, as I see it, stem from Terragen's original charter to produce great looking still pictures then extended to animation as an after thought. Flicker isn't a problem with stills but it is serious with video. Each frame having to re-create the light sampling and geometry for the current still is as the heart of both problems. This "Global Illumination Caching" seems to address the lighting flicker. The logical next thing would be to address the geometry popping artefacts.

First I would like to understand what "Global Illumination Caching" is. My impression is that a new mechanism was added to create a light sampling method that would smooth out the lighting between time frames. I would like for someone with the knowledge to verify or correct me on this. This new feature is one of the next things I want to spend time to investigate.

We have had discussions about the geometry popping problem before. It is my opinion that the best way to get rid of this in a future version is to have a preliminary pass that will build the geometry once that will be used for the whole animation sequence. The detail of the geometry at any one place is dependent on its closest distance to the camera while in view of the camera. While some of us have expressed that they think that the geometry data set would grow exponentially, and be unreasonable, I am not so sure. If you take two adjacent frames, the perspective is nearly identical and so the single geometry that would be suitable to use for both frames would be almost identical to the geometry needed for only one of the frames individually. So there you are already building only about half the geometry. This only shows that the geometry would not grow exponentially nor even linearly with the number of frames involved. Indeed, I suspect that typical geometry growth would only be modestly incremental as the camera moves through space. The geometry can't be very different from frame to frame or the viewer would lose perspective (as well as very annoying).

Using this method, geometry popping would be totally eliminated even with detail quality set to absolute minimum although individual polygons might become perceptible. But at least they would be consistent from frame to frame (and thus no popping). It would complicate geometry building because to calculate "distance from the camera" for the purposes of controlling detail then the software would have to instead lookup the closest distance to the camera path when the geometry is in view of the camera. But I think having to build the geometry only once for a whole animation sequence would mean you would more than gain back the compute time lost in the more complicated "distance from camera" lookup process described above.  It would also greatly simplify exporting and loading a geometry created by Terragen into another package because you would only have to do it once per sequence instead of once per frame. I think this is the best solution for eliminating geometry popping.

[Tangled-Universe]

Hi Pablo,

There's quite some information on the GI cache feature on these forums. Use the search I'd suggest

I can't say for certain that caching the complete geometry for the animation is impossible, but I'm pretty sure the amount of RAM required to bake all displacements into memory will be vast. Really vast.
In 2.4 there's also the animation check button which enables/disables certain settings which add in flickr and popping issues.
There are some other options which improve geometry popping which you also can find with the search

[Oshyan]

To my knowledge Terragen 2 has never had a focus on still images. The animation module was always an intended part of the product, for example, it just took a while to build it properly. It's certainly not an after-thought. Rendering animation in typical cases has actually worked fairly well from early on (see the "Mars pull-out" animation on our site, done with an early alpha!), however there are certainly more challenging and unusual situations that even today are difficult to render without some issues like you describe. I understand that Vue and other apps have their own problem scenarios too, in fact flicker and aliasing in motion were, I believe, somewhat notorious in Vue animations until recently (they too now have a GI cache feature, for example).

There has been a fair amount of work done for the past couple versions of Terragen to address flicker, creating features and settings like GI caching which I would guess were not available (or you were not aware of) when you did your animations. There are still some situations, such as extremely low lighting angles and long shadows coming off of out-of-frame geometry, where there can be problems. But the combination of GI caching, and region padding for ray detail and GI, addresses many of the pop-in issues. Other settings, which the "check animation settings" button sets correctly for you, address other possible areas of flicker. I would suggest you try some animation with newer versions, and make use of the newer tools. Documentation on GI cache use is here:
http://www.planetside.co.uk/wiki/index.php?title=Terragen_2_Global_Illumination#Rendering_with_GI_cache_files

Regarding the idea of pre-generating scene geometry, what you're talking about is essentially caching, but for geometry. It is feasible using some methodologies, though pre-generating an entire camera move might be too memory intensive. More likely would be some kind of inter-frame geometry caching, which would accomplish the same goals, but wouldn't require huge amounts of precomputation and storage. However it's not a feature we have in the time line soon, I'm afraid. Certainly something we're aware of and would like to do one day, if possible. In the meantime we'll continue to look at shorter-term solutions to flicker issues.

I would encourage you again to try animation on newer versions and bring up specific issues here to see if we can help resolve them.

- Oshyan

[PabloMack]

It has been some time since I experimented with Terragen. I certainly need to get back into it. Admittedly, any geometry that is changing could not be pre-generated once for an animation. Also, you would not want to include models that you already have geometry for. But one thing is for sure, the longer you put off implementing a feature in software while developing it for other features, you tend to paint yourself into a corner and the architecture you have created tends to resist adding the features that you have long wanted to implement. I am a software developer and I have often been bit in the rear by my own doing. 

P.S. I don't see how to navigate to the page you gave a link to above. Is there some sort of index for the Wiki content or do you just have to hit and miss with searches?

[jo]

Hi Pablo,

If you go that page Oshyan linked to you will see a bunch of things in the sidebar, including a "Main Page" link which takes you here:

http://www.planetside.co.uk/wiki/index.php?title=Main_Page

That's the main page for the docs. The Global Illumination page is available from the Reference section.

As Oshyan said, TG2 has never been about solely still images. Right from the start it was developed for use in motion pictures (i.e. movies) and has been used for animation in a wide range of productions.

Regards,

Jo

[PabloMack]

I see that, for "official" content, there is an index right there. It is understandable that user supplied content would be much more difficult to organize. I will spend some time looking around and reading what has been written. Thanks.

[PabloMack]

I can't say for certain that caching the complete geometry for the animation is impossible, but I'm pretty sure the amount of RAM required to bake all displacements into memory will be vast. Really vast.

In no way do I want to suggest baking all geometry, only the fractal-type geometry that is computed differently from frame to frame because of camera movement. Since its detail is a function of distance to camera, its geometry actually changes from frame to frame. To my understanding, displacements, loaded models and most every other thing that is deterministic and computed exactly the same every frame regardless of camera proximity certainly has no need to be pre-computed. Then you have anything that is animated certainly has to be computed every frame because they are supposed to be moving, thus precomputing of their geometry is a useless endeavor. But, as Oshyan pointed out, the most severe geometry popping comes from geometry that is out of camera view casting shadows that are in camera view. That was actually the case I talked about in the animation I did of Oshyan's benchmark. But these are also from fractal-type geometry that is changing its morphology only because the camera is moving. I would think that any displacements off a precomputed non-moving geometry of these fractal-type surfaces would be computed exactly the same regardless of camera position. But maybe I am wrong. Anything that needs higher detail as the camera gets closer has the potential of geometry popping. But if you don't need it because the camera is not close enough, then it is a non-issue. Anyway, I've said my piece. Thank you all for listening.

[Oshyan]

As you say, off-camera geometry is really the main source of remaining pop-ing at this point, and although you could certainly include an off-camera "padding" setting or something as part of pre-computing geometry, the real solution to the off-camera geometry issue is ultimately separate from the potential benefits of caching. If it were possible to compute displacement at full resolution 360 degrees around the camera, it would solve the issue. Granted, with tremendously increased render time, but the point is that caching is really just a way to take advantage of previous geometry calcs on future frames, and unless the out-of-camera geometry issue is solved (separately, basically), then the issue will remain.

In any case we certainly agree it needs to be addressed. Fortunately it is relatively seldom an issue in most of the animations I have created and seen from others. It's quite easy to create a scene that will immediately show problems, but practically speaking the effects are much less common.

- Oshyan

[PabloMack]

As you say, off-camera geometry is really the main source of remaining pop-ing at this point...and unless the out-of-camera geometry issue is solved (separately, basically), then the issue will remain.

You bring up an excellent point. I think that a 360° geometry caching is probably un-wanted. It seems likely that geometry caching might not be needed at all if the current system has no problem with popping of actual geometry that is in view of the camera. As you said, the shadow popping problem is principally caused by geometry that is out of view of the camera by casting shadows from light sources, in most cases the sun. The solution may simply lie in adding this consideration in the distance from camera determination for geometry detail generation. Some sort of ray trace from camera to visible surfaces to shadow casters of light sources could possibly be used to determine out of camera detail. Probably the "in view" geometry for the current frame would have to be created before this evaluation could be done. This is necessary to know what geometry exists to even receive shadows. Then the necessary "out of view" geometry would have to be created for proper shadow casting on now known geometry. This two-phase geometry creation may be the most difficult thing to implement.

The distance from camera to shadow caster via a bounce off of shadow receiver would be used to determine the level of detail that is necessary for out of view shadow casters. This would be distance that the shadow is from the camera plus the distance of the shadow from the shadow caster. Increasing either distance would lower the need for resolution of the geometry that is out of camera view. As the distance from camera to shadow receiver increases, the observed shadow geometry shrinks. Likewise, as the distance from shadow receiver to shadow caster increases, the observed shadow geometry also shrinks. As you imply, this problem might be reasonably tackled head-on.