Please have a look at a short Quicktime here:
http://www.motr.net/TG/cloudTestMovingY.mov (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
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.
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
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+
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
Will this issue be fixed later so we don't have to bump the GI blur radius up?
- Terje
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
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?
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
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
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
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.
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
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
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
Having worked with MR, and a bit of Vray, I would think it near impossible to shoehorn them into rendering TG scenes. Displacements are not the strong point of Raytracers... So much data must be in memory to calculate GI, that I would think they would choke. That said, you are doing some form of raytracing/GI in TG, so perhaps not impossible. But Scanline renderers would have much more success at rendering displacement-heavy scenes like those in TG.
I'm curious to know how TG is doing it's raytrace functions without blowing out memory.
In general, integrating a 3rd party renderer is no small task. Especially if the application was not designed to plug in renderers. To this day, Maya/MR integration needs work;)
Plus, it seems the renderer in TG is the breadAndButter of the app. It's not something that needs replacing... just tweaks, and proper documentation. I'm sure once the tools are made clear, we'll be able to use them more effectively.
Andrew
Spot on Andrew. There are of course improvements to be made, but it's a bit of a leap to consider ditching the entire renderer when it's purpose-built for this kind of stuff. :)
- Oshyan
I don't remember advocating that the internal render of Terragen be ditched, if that is what it seemed like then sorry for any misunderstanding I was merely trying to help. End of Line.
;D
Regards to you.
Cyber-Angel
"GI blur radius" is relative to the spacing of the GI pre-pass samples (ignoring supersample prepass). Therefore, if you increase "Detail" or "GI relative detail", the blur area in image space will be reduced, so that increasing Detail or GI relative detail improves overall detail without needing think about the blur radius. Before blur radius was promoted to a user-adjustable parameter, the idea was to always use GI sample quality to address flickering problems or other quality problems not specifically related to detail. That should still be possible in most cases, but in earlier versions there were some bugs which meant it didn't always work that way.
In recent builds you should be able to remove flicker if you set the GI sample quality high enough. GI blur radius helps a lot but it blurs away the detail that you probably want. 300 virtually flattens everything. Try GI blur radius at no more than 50 and increase GI sample quality until the flicker is gone. If too much detail is lost, reduce the blur radius and maybe increase GI sample quality even further to compensate.
Matt
Quote from: Matt on May 18, 2009, 01:55:35 PM
"GI blur radius" is relative to the spacing of the GI pre-pass samples (ignoring supersample prepass). Therefore, if you increase "Detail" or "GI relative detail", the blur area in image space will be reduced, so that increasing Detail or GI relative detail improves overall detail without needing think about the blur radius. Before blur radius was promoted to a user-adjustable parameter, the idea was to always use GI sample quality to address flickering problems or other quality problems not specifically related to detail. That should still be possible in most cases, but in earlier versions there were some bugs which meant it didn't always work that way.
In recent builds you should be able to remove flicker if you set the GI sample quality high enough. GI blur radius helps a lot but it blurs away the detail that you probably want. 300 virtually flattens everything. Try GI blur radius at no more than 50 and increase GI sample quality until the flicker is gone. If too much detail is lost, reduce the blur radius and maybe increase GI sample quality even further to compensate.
Matt
Thanks for these explanations Matt. So if I understand correctly the GI blur radius is not something "fixed". I mean, a blur-radius of 50 is not 50px or 50% or whatever....it's dependent on quality settings.
Anyhow, with this in the back of my head, will these suggestions also help to solve seams between images for cubemaps for example?
Martin
Thanks for the info. I'm still not 100% sure how to tune my blur size, but guidelines are good to have. I'll try using the gi detail settings first, with blur set to less than 50 or so. Thanks
Andrew