Source of Flicker?

Started by MrHooper, May 06, 2009, 04:06:58 PM

Previous topic - Next topic

MrHooper

Please have a look at a short Quicktime here:

http://www.motr.net/TG/cloudTestMovingY.mov

The animation is simply of clouds with a translate in the vertical direction (Y).  This is to see what it looks like, which is cool, but does anyone have an idea where the flicker on the underside of the clouds is coming from?  My next guess is GI settings.  My settings for this render are as follows:

Detail - .65
AA - 2
GI rel detail - 2
GI sample - 2
GI blur - 8

Atmosphere samples - 50
cloud quality - 1
cloud samples - 135

RArcher

The first thing you want to do is increase the GI Blur radius to around 300 or so.  This usually does not impact render times much so it is a good first step.  If that doesn't work, then you will need to play around with the Ray Detail Region, and Ray Detail Region Padding settings under the advanced tab of the render node.  Changing these settings will have an impact on render times.

MrHooper

Is GI blur in pixel units?  If so, wouldn't 300 kind of ruin the GI accuracy?  I was thinking more GI samples (yes higher rendertimes), but increasing blur is probably wise too... just 300 sounds like a lot, unless the units are in world meters.  Or am I just not getting how GI works in TG?

Andrew

RArcher

Andrew, I'm afraid you will have to wait for someone from Planetside to let you know just what exactly the GI Blur units are in.  All I know is that in the animations I have tested you won't really notice a reduction in shadow popping until you get into some higher numbers, 300+

Oshyan

As hinted at by others, the flicker is due to GI differences. The easiest solution is to increase the GI blur radius, though I'll be honest I'm not sure what the unit of measure is there. You can try 200-300 or so on a single frame and see if the detail loss is too much, but it's usually not bad. You can also try to balance that with less blur and increase of GI Sample Quality. GI Relative Detail isn't really going to help you, so I'd leave that low. You might try 2/4, with a 100-200 GI blur.

The Ray Detail Region settings probably won't have any effect here since the problem is in the middle of the frame and not evidently due to any out of frame elements.

- Oshyan

sjefen

Will this issue be fixed later so we don't have to bump the GI blur radius up?

- Terje
ArtStation: https://www.artstation.com/royalt

AMD Ryzen Threadripper 1950X
128 GB RAM
GeForce RTX 3060 12GB

Oshyan

I honestly don't know. Hopefully we can find a broader solution. But if we could do that already, we'd have done so. ;) GI Baking would be one possible solution. If it helps any to know, many other GI renderers have the same problem if baking is not used.

- Oshyan

domdib

It would be great if we could have GI Baking, as even with the new Ray Detail Region setting I am still experiencing minor seams in cropped images (although it does seem to help). Is GI Baking a feature that would be very complicated to introduce?

Oshyan

I'm not in the development side of things so I can't say for sure, but I think it would take a bit of doing to get it working well for animations. Either you'd have to compute GI for the entire scene (extremely memory and/or disk intensive), or you'd have to do it progressively as the camera moved through the scene, with some kind of interframe caching and blending. Non-trivial I reckon. But certainly possible.

- Oshyan

sjefen

What if it only calculates new GI when it needs it?
Like the first image gets a full GI calculation and after that, it uses the same GI pass and only replaces the ones that needs to be changed.

- Terje
ArtStation: https://www.artstation.com/royalt

AMD Ryzen Threadripper 1950X
128 GB RAM
GeForce RTX 3060 12GB

Oshyan

Right, but you have to figure out a good way to blend them, otherwise you still get flicker. Less frequently perhaps, but still flickering (whenever it recalculates). If we had a solution for blending GI solutions between frames, this would be a solved problem already.

- Oshyan

JimB

Quote from: Oshyan on May 10, 2009, 08:06:28 PM
If we had a solution for blending GI solutions between frames, this would be a solved problem already.

What if the GI sampling was firstly pre-sampled and combined before the full render (a pre-pass), based on the camera's view throughput the animation, instead of done on the fly? Not necessarily for every frame, but could be user-specified. I'm assuming it's possible to associate a sample point with a polygon, and I've never written a renderer, so it might not be a sensible suggestion. But in terms of render times it shoudn't take any more than normal.
Some bits and bobs
The Galileo Fallacy, 'Argumentum ad Galileus':
"They laughed at Galileo. They're laughing at me. Therefore I am the next Galileo."

Nope. Galileo was right for the simpler reason that he was right.

Cyber-Angel

Why not contact the guy's who develop Vray and work with them to make Vray for TG2 3DS Max and Maya have Vray support and have a version for their respective software: Vray has many here will know is an industry standard application notably in the architectural visualization field, but is also widely regarded in other fields these include FX and related fields.

Taking these factors into consideration and that Vray according to feature specification that their GI in relation to animation is flicker free (Note: I Have not used Vray so can not attest to this nor verify its accuracy): further more it is common with more advanced 3D applications to have 3rd party render support a well known example would be the integration of Renderman into several key applications; yet another well known one would be the Brazil R/S for 3DS Max, this practice then is well known and is not new.

By having a version of a well known version of a 3rd party render such as Vray for TG2 has the following effects:

1: Increased Product Profile: Industry

By having support for a respected and industry leading 3rd party render such as Vray this will raise the profile within the key parts of the industry that are the key sales demographic of TG2: with a version of Vray for TG2 and key formats such as .FBX will be an enabling factor into TG2 sliding in a more seamless fashion into other people pipelines.

This would allow with the right arrangement's in place for TG2 to have penetration into market areas that is dose not see at this juncture and with its support for Vray Planetside would see cross pollination of the to user bases, which factoring in an increase in industry exposure should see potential for solid growth and sales.


2: Increased Product Profile:Customer 

The case for support of a 3rd party render is the increase in product profile that Terragen will get within the consumer (End Users) and the wider industry where certain sectors still regard Terragen with the perception of what might be seen as hobby-ware. With the inclusion of support for a well respected industry leading render such as Vray perception will change in the consumer base for Terragen; thereis however a caveat to this and that is:

   2a: That the first integration of a version of Vray (or alternate third party render chosen) must work seamlessly first time; as in certain sections of the CGI community there are no second chances.
 
   2b: That terragen be able to use the full range of features offered by the third party render system weather this be Vray as advocated or other; the user community who have worked and used this third party render would expect to able to utilize, the features they have become accustomed too, and while there would be variations one would expect that are host application specific they would expect that there would work flows they are use to in place.

With an increased customer profile and thus further reinforcement of product reputation comes with potential for increased revenue streams which can be plowed back into product development and/ or company expansion.

_________________________________________________________________________

Regards to you.  ;D

Cyber-Angel               
                                       

MrHooper

Thanks for all the replies!  I did get a test working better with larger GI blur settings, but I went lower than 200-300, I went with 50.  Then after rendering a larger version, I noticed the flicker was back, so I'm guessing the blur radius is in pixels.  I would love official confirmation of this if possible.

Assuming i'm right, then I would have to up the blur radius for higher res images... thus 100-200 would be better for full HD, vs the SD version I rendered at first.  Thanks again, for the suggestions.  I come from a MR/Maya background.  Earlier versions of FG/GI in that were pixel blur based, so that would be expected... but increasing it to settings that large, would ruin accuracy in MR, so I assumed the same for TG... but it seems the blur radius can go higher than I thought without obliterating the accuracy.  It does diminish, but not quite in the same ways.  I have more testing to do, but any info from the developers on the units the GI settings use would be nice.

Andrew

Oshyan

Getting TG2 to work with Vray as a renderer is "non-trivial" to say the least. In other words it's a major undertaking. We can't even know for sure if Vray could handle the massive amounts of displacement TG2 deals with. No other renderer I know of really can, aside perhaps Zbrush and Mudbox, but both are GPU-based and not dealing with atmosphere, populations, etc. There is nothing that does with TG2 does as well as it does it. Try doing procedural terrains in Vue to the same degree you can do in TG2...

Andrew, I'm afraid I don't know what units the GI blur radius is in, but I'll try to find out for you.

- Oshyan