Render settings on Mac dual quad core

Started by mattman, February 17, 2011, 12:43:22 PM

Previous topic - Next topic

mattman

Dear All, I am new to Terragen and am working on rendering out a high resolution panoramic image for use in a museum display as a back drop. Its sky and water. I am trying to render 3000x3000 pixel tiles and then stitch them together for printing. Unfortunately I need a fairly massive image to pull this off - about 30,000 x 20,000 pixels to print at 150 DPI over a wall area of about 20 feet.

I am a little confused by the render settings and I am getting some errors that I dont know how to rectify.

I have set 4 threads as max and min and the subdivision cache is set at 1600 (is this total megabytes and then this gets divided by threads in use?). This setting seems to be cooking along OK so far. Previously I had this set at 16 max and 1 min with 2400 cache. This errored out in the end. Looking at my activity monitor it says that Terragen is using 7 threads with 2.2 gb real memory and 2.3 gb virtual memory - this is on OS X.

What is the relationship between all this? :)

I would think that I have 8 cores therefore 8 threads but it does not seem to work that way......

I obviously would like to fine tune my settings to get shortest rendertime!

I attached my file in case someone can see what I am doing that is wrong or right!

Thanks in advance!

Best,
Matt

Volker Harun

Honestly ... quite a huge image. I hope that you are familiar with the discussed problems of cropped renders, as there might occur some lighting-mismatch within the tiles.

At the moment I am rendering on my Mac with 3 threads, which is balanced for speed and heating of the MacBook Pro. TG2 uses 5 threads (maybe additional UI-threads and so on). Using the full 4 threads of my machine would reduce rendertime by only 5-10% - having no more resources for anything else.

I will have a look at your file later, but for sure you might want to reduce the subdivision cache to about 100k per thread and you might want to set the render buckets to a value of about 128 / 128 ... this will reduce memory usage and might speed up the render time.
Keep in mind, that every render thread is using its own memory, going over 4GB memory usage for a 32bit application will result in errors. I guess (!) you should go for a max of 2 or three threads ... to keep the memory usage as low as possible.

Regards,
Volker

Tangled-Universe

I suggest you run 2 instances of TG2 at the same time.
Configure each instance to use 1 thread minimum and 4 threads max. Volker mentioned going beyond 3 threads isn't giving much better performance, so you might consider setting it to 3 max.

Usually a 100Mb cache size per thread is sufficient. So using 1600Mb for 4 threads is a bit of overkill.

I attached a .tgd where I changed some settings. It reduced the rendertime of a crop from 1m55s to 1m18s = -32%. Given the size of your project it's a significant gain I'd say.
I'll explain briefly what I changed:
- Changed cache size to 100Mb/thread.
- Changed render bucket size to 128x128. Especially for water at the bottom this works nicely, as you don't have to wait ages for the last bucket to finish, since it's 4 times smaller.
- Changed GI from 2/2 to 1/3. Your scene doesn't have challenging shadows which require high GI settings.
- Increased AA to 4. Why? See next point.
- Enabled ray traced atmosphere. The quality of raytraced rendered elements in TG2 depend on the AA setting. AA also works better with settings of power of 2, though not that important here. Raytracing atmosphere often allows for less samples needed to get a clean result, compared to the normal rasterized renderer.
- Reduced samples in clouds. Especially your cumulus, which had so many samples that it resulted in a quality of 3.x...that's very high!

All in all that resulted in a similar result, maybe even slightly better, and 32% rendertime reduction.

A couple of notes:

You disabled "do raytraced shadows" in the rendernode. By default this should be enabled, as it generates accurate shadows on your surfaces. Now the shadows of the ripples on the water will not be accurate. You'll only get darker shades on the faces facing away from the sun, but the water-geometry itself will not cast any shadows anymore.

Volker mentioned mis-matched lighting when rendering in crops. A 100% proof way of avoiding this is to use a fill light setup instead of GI. However, this will especially greatly affect the rendered result of clouds.
You could use the "GI prepass-padding" option in the Advanced tab of the rendernode. Set it to 0.2, for example, and it will calculate the GI outside the camera frustum at a size 20% of your image size. So if your image is 3000x3000 pixels then the extra GI will be calculated 0.2 x 3000 = 600 pixels extra on each side of your image.
This way it is more likely that adjacent crops have more matched lighting. You would need to play with the value though.
A drawback is that it increases rendertime.

I hope this all helps.

Cheers,
Martin

mattman

Dear Martin,

Much much appreciated! Thanks for the explanation and I will play with the file.

Thanks again.

Best,
Matt

Upon Infinity

Mind if I ask why something that big has to be 150 dpi?  Seems pretty fine for something people are going to have to be about 20 feet away just to see.  Unless, of course, you're attempting to 'wow' them when they step up close to it, that would make more sense.

mattman

150 DPI is about the bottom end on printing, it gives acceptable results and looks good to the eye.

A rule of thumb I use is that anything above 150 DPI is a waste as you cannot see the difference.

I have done some tests with below 150 DPI and it looks yuk and yes its definitely my objective to wow people!!

Best,
Matt

Floating.Point

#6
Just a quick note.

There is no "minimum standard" or "bottom end" for resolutions for print.
It completely depends on viewing distance. (14 feet billboards will often use between 20 and 02 ppi- for example) In fact getting the ppi balanced correctly not only saves time, but can actually be easier to look at!

An easy to read article is here:
http://www.northlight-images.co.uk/article_pages/print_viewing_distance.html

Formula for calculating appropriate ppi:
ppi = 1/((distance x 0.000291) / 2)


Upon Infinity

Yes, thank you floating point.  Obviously someone who has also worked in the print industry.  Not that I don't appreciate the effort, I even welcome it, hence my nick, but 30,000 x 20,000 is beyond insane.  Think about what it takes for Terragen to crank out a 3000 x 2000 image, it's not 10 times the size, it's 100 times the size.  And thinking of you attempting to photoshop that 30,000 x 20,000 image together and what it'll scratch disk to your hard drive will keep me awake tonight.  To put in photographic terms, it's the equivalent of taking a picture with a 600 megapixel camera.

And that's to say nothing of the output.  Most printers capable of the print size you're thinking of do not print at 150 dpi.  And unless you've already confirmed that it does, or you are outputting on a smaller scale device and physically stitching them together, in that case I wish you the best, and don't lose the order they're printed in!

cyphyr

Very useful article FP, Bookmarked!
Richard
www.richardfraservfx.com
https://www.facebook.com/RichardFraserVFX/
/|\

Ryzen 9 5950X OC@4Ghz, 64Gb (TG4 benchmark 4:13)

jo

Hi Matt,

Some good advice from others. I can give some specific information about the number of cores to use, having just done a lot of benchmarking. Right now if you have a dual quad core Mac Pro (as I do) then the best CPU utilisation will come from using 8 threads. A dual quad core Mac Pro can theoretically use up to 16 threads but right now as soon as you get over 8 performance will actually start to drop off quite dramatically. Using 8 cores won't be anywhere near twice as fast as 4 cores but it could very likely be a bit faster.

Of course with such a large image memory becomes an issue and that means the subdiv cache size becomes important, so using 8 cores might not work out for you. The others have advice about this, but I thought I would mention the CPU situation anyway.

Regards,

Jo

Floating.Point

Quote from: cyphyr on February 18, 2011, 04:23:48 AM
Very useful article FP, Bookmarked!
Richard

No worries Richard!
Happy you find it useful :)