Dandelos larch tree, walli's grass patchs, Mt Mckinley dem. Render time seemed way to long ? these are the settings:
Render Information:
Time 40hrs:26min 3106050 micro triangles 600 X 600 Population.(Trees & Grass)
1300X800
Render settings .7
AA 2
Super Prepass and GI Surface details Enabled
Ray Traced Shadows Enabled
Trees Ultra
Grass very high
Mist Quality 64
Cumulus layer 1 Quality 64
Cumulus layer 2 Quality 40
Maximum threads 16 Set
Intell I5 2.27 GHz
Nvidia GeForce
8 GB Ram
64 Bit win 7 OS
Good start on this image. I would bring the camera exposure up higher. Or alter the gamma and contrast in the render controls.
Your issue with the render time may be from using too many threads. They competed with each other for processor time. Try a small 400 x 200 pixel image using 16 threads, then test it out with 4 or 8. I use a P4 HT 3 GHz. This may have taken my computer about 16 to 20 hours.
If you are using Terragen 2.2, you don't really need the GI turned on, or the super sample prepass. Just turn on the raytrace atmosphere. I have been having good renders with the atmosphere samples set at 24. The clouds still have to be set fairly high. I hope this helps.
first try reading Oshyan's recommended render settings.
then:
You don't need:
GI surface details enabled
Ray traced shadows enabled
Trees at ultra (very high will do).
Hi, Danny, good to see you round here. :)
Kevin F said it all pretty much, the first two are especially render heavy. You might also consider using 'ray trace objects', found in the render node. This will disable the object quality issue completely, making your AA the overall object quality control. The population quality drop-down selection will then have no effect at all and needn't be worried about.
You'll see in the atmosphere and cloud nodes where you 'enable ray traced shadows', there is a description beside that check-box with the ideal settings to use that feature. Generally, if you need a sold object to cast shadows onto that particular layer. Here, I'd say you don't, it'll just increase your render time significantly, as will GI surface details. A lot!
When you say 'cloud quality=64 and 40', I hope that is the sample count and not the overall quality slider value you mean! I'm sure it is because, we've been over that one before, remember? ;)
If you use 'ray trace atmosphere', like Henry suggested above, you could easily get away with lowering cloud quality to about '0.25', saving more sampling time still. Using atmo samples of 24 to 32, instead of 64, should be enough for this scene using the ray tracer with good AA settings.
After reading Oshyan's 'render settings recommendation' thread, read this one from Matt on using the ray-tracing options; http://forums.planetside.co.uk/index.php?topic=8300.0
:)
object quality settings are not needed (and do not affect-the objects) if you have 'ray tracing objects' enabled...
great start all the same Danny!
looks good!
shoot, I missed dandelOs first lines!
doh!
Thks for the quick reply all your input is very helpful, Oshyans thread is very informative, I appreciate the tech help. The image is a bit flat I agree even for a misty rainy type day. Lots to work to do. Thks
Anyone with the same problem as I was having, lowering the threads helped substantially. Runs much smoother as well as lowers render times. Also the ray tracing objects instead of quality settings helped out as well Thks njeneb
*Martin you are correct I was referring to samples in my render settings
Overhead from running too many threads can sometimes slow things down. On intensive scenes I'd lower them a bit
Smaller buckets seems to manage the memory much better with a high amount of threads. I know from my own experience with a complicated scene that I was getting raytrace errors and incomplete renders with 8 threads @ 100mb for each thread using the default 256 buckets size. Then reducing to 64 for the bucket size using the same settings I got no raytrace errors, plus the renders would finish faster because in the past 1 thread would always be stuck on some bucket that had a complicated part of the image, but now my buckets are smaller, that work is distributed more evenly.
Njen, that's in general a good approach to do for every project you're working on.
I'm not very surprised that 64px bucket size worked faster than 256px buckets, but in my experience 64 is slower than 128.
Just wanted to share that with you.
Also, since thread-scaling is not optimal I would render with 2 instances of TG2 which both use 4 cores. Especially on big projects/animations this could save a significant amount of time.
There's always the GI issue though. GI padding adds quite some rendertime so using that too much might cause the gain to be lost quickly.
It's definitely worth investigating I think.