High Resolution Rendering

Started by PCook, August 08, 2012, 12:03:52 PM

Previous topic - Next topic

PCook

Hi Folks;
I discovered Terragen2 last week while investigating 3D terrain software for a project. I've invested a good deal of time exercising TG2 (free version) and generally like what I see. What I need to do now is determine if the paid TG2 edition will be practical for the rendering of large still images, such as in the 11x17 inch range, which would result in 16 million pixels at 300 DPI. I would appreciate any suggestions for managing the workflow of high resolution stills. And I would like to hear about any challenges that need to be overcome attempting such high resolution image rendering with TG2. I am not interested in animation rendering at this time.
Thanks!

Tangled-Universe

Welcome to the forums,

At such resolutions the challenges lies in getting it to fit in your RAM budget.
Important factors are of course the amount of RAM you have and whether you use many (detailed) objects.
However, also render settings plays an important role.

As you may have noticed yourself TG2 uses more memory as soon as you increase the detail slider closer to 1 (which in >90% of the cases isn't necessary).
Also GI relative detail contributes very much to the amount of RAM being used. Both detail and GI relative detail go hand in hand here.
Hence 'relative detail' for GI, which basically means that the GI detail is relative to the detail setting.
So if detail is 1 and GI is 1 then it uses more RAM than detail 0.5 and GI 1. Just as a simple example.

The problems you will encounter will be unique for every scene, so it's hard to say exactly what's best to do without having a scene/setup as a reference.

All I can say for now is be gentle with rendersettings and keep object-count and polynumbers as low as possible.
For distant trees/bushes you can get away with low-poly objects, which you need thousands of, but for close-up you need high-poly models, which you only need a couple of dozen of. It's up to the user to be clever with setting this up.

I'd say/suggest make a start with the image and start a thread in image sharing and we will guide you along the process and the pitfalls.

Cheers,
Martin

PCook

Thank you Martin for this excellent overview. It's becoming clear to me that TG2 rendering is not an exact science, with an interplay of several variables. And it does sound like rendering is not something one wants to dive into with brute force settings. I am bit dismayed by the lack of TG2 documentation, but with help from the community TG2 just might, eventually, be an excellent asset for me if large renders can be managed.

What I would like, ultimately, is to render out high resolution images destined for printing. It seem to me that there are two practical solutions: 1) build out a beefy personal computer and put it to the task of TG2 renders and/or 2) farm the render job out to RanchComputing.

These days we can build powerful PC's fairly cheap and I would be ok with building a dedicated rendering PC. Can anyone suggest a RAM amount or would it suffice to say "as much as the box will hold"?

The RanchComputing solution looks attractive, especially for animations. But they are being honest in not being able to closely estimate a price on still rendering. What I came away with from reading their website is "give us the job and we'll bill your credit card when the job's done". That "blank check" approach is a bit intimidating when you haven't had experience with farm rendering. I suspect that high resolution still rendering could get expensive compared to a dedicated PC with, of course, the advantage of much faster render turnaround times. Does anyone have experience with using RanchComputing for high resolution still renders from TG2 that might be able to ease my apprehension?

Given the options of a PC dedicated to TG2 rendering versus RanchComputing (or some other rendering service) what advice would you give for rendering approx 1 high resolution still image per week on average? Or, is there another rendering option I'm overlooking?

Thanks!
Pat

Oshyan

#3
Large renders are generally not a problem, and in fact 11x17 at 300dpi (5100 pixels on the longest side) is in the middle of the range for resolutions I've seen people rendering at with Terragen. The highest I've seen so far is 16,000 pixels on the longest side, but that was rendered in tiles on a render farm. Forum user "Dune" has done a number of high resolution renderings for large print installations as well. Ranch Computing has a benchmarks page that shows a 12,000 pixel image and gives you an idea of render time as well:
http://www.ranchcomputing.com/terragen-benchmarks-produit.en.html

Memory usage for rendering is dependent on a variety of factors, particularly the size in memory of the assets you're using in your scene (objects and textures), the detail settings for rendering and GI, and the antialiasing level. The number of cores/threads you are rendering with is also a potentially important factor since you need a minimum of 50MB (and ideally more) per thread for the render subdivision caches. But on normal home machines this usually isn't as big of a factor as the others since most such systems have 4 or at most 6 cores and use up to 8-12 render threads. At 100MB/thread (the recommended setting), even a 12 thread system will only use 1200MB for the subdivision cache. 1200MB may seem like a lot, but you can easily have 16GB or more in a good, modern system so it's not necessarily huge.

Estimating render time can be done with a reasonable degree of accuracy in many cases, based on lower resolution renders of the same scene. You would want to use the same render settings as you will use for the final render, except render at some fraction of the final render size. So if you're aiming for 11x17 at 300dpi, that's 3,300x5,100, you might want to render at 1275x825, which is going to be 1/16th of the pixel area of the larger render, and so should take *approximately* 1/16th the time. If your render at that resolution takes an hour, you can reasonably estimate that your higher resolution render will take roughly 16-20 hours. You can use these kinds of estimations to predict cost on a render farm, just keep in mind they are only estimates. You'll want to test the effectiveness of that kind of estimation on your own scenes, of course.

If you want to build your own system, I would recommend a minimum of 16GB of RAM; get 24 or 32GB if you can. Fortunately RAM is quite cheap right now so it's not difficult to get that much or more in a fairly reasonably priced system. If you anticipate doing a lot of high resolution renders and don't mind your system being tied up on rendering regularly, then buying a machine is probably the most economical choice over the long-term. However, depending on whether you will be selling the results and thus may have a small budget for each piece, a final render at high quality on the Ranch render farm might be the most convenient and responsive option. The 12,000 pixel render would have taken several days on a fast home workstation, whereas it was less than an hour on the render farm.

In general Terragen 2 is fairly economical in terms of memory usage when rendering (with a few exceptions such as high GI settings). If you loaded similar objects and textures into another application to render a similar scene, you'd probably have similar memory usage, perhaps even greater, depending on the application. Which is to say, if you can't render a particular scene at high resolution in Terragen, it's quite possible you'd have the same problems with many other 3D applications, assuming the memory usage in the scene is driven largely by the assets in use and not the render settings. Making sure that's the case is really the goal and should be fairly easy if you just follow some simple guidelines about render settings. One of the most important, as Martin mentioned, is that a detail of 1 is seldom necessary, 0.75 usually provides very good deal and will use less memory.

- Oshyan

PCook

Thanks for this great info Oshyan!

What I gather from your explanation is that a dedicated rendering PC can be effective for my 11x17 print size objective, while large resolutions might be best done by a rendering service. I consider this good news because I would prefer to remain in control of the rendering and, as you pointed out, a dedicated rendering system would be more economical in the long run (for my 11x17 target).

You have my interest in a dedicated rendering system to the point where I'm spec'ing out a system. I'll make a new post with some questions I have about a dedicated rendering system.

As an aside, the excellent and complete explanation you gave in this post is about 98% perfect as a section on rendering for a TG2 user's manual.

Pat

Oshyan

Glad to hear that info was of help. Definitely post the specs of the system you're considering (and where you plan to buy from) as I'm sure we can help you get the most bang for your buck.

- Oshyan

RenderFred

I would also like to point out that appendix B of our RANCH for Terragen PDF User Guide (http://www.ranchcomputing.com/pdf/RUG_Terragen_en.pdf) is dedicated to how the RANCH renders still images, and why it is not possible to have a simple estimator for stills. Yes, reading the manual _is_ useful  ;)
Chief Technology Officer
The RANCH
www.ranchcomputing.com

PCook

QuoteYes, reading the manual _is_ useful

I think there's a good lesson in this Fred. Your website is heavily slanted toward animation rendering to the point where readers interested in still rendering are left hanging, at least that's the conclusion I came to last week. Take for example on the "Estimate Time & Cost" page of your website that states "It is _not_ to be used to estimate still image projects". Fine, yet that page provides no reference at all where still rendering is discussed. One could easily conclude that Ranch Computing is not interested in still rendering. Even my review of your FAQ page did not yield enough info about still rendering. Yet, as it turns out, such information is deep in an Appendix of a PDF of a manual I don't know to be relevant to me because I haven't decided to use your service. People cannot be expected to know the details of your service as well as you, so they need to be guided to where they can learn about what you provide, especially if that info is buried.
Pat

jaf

Another option that might work in some cases is a program called "Perfect Resize 7 Pro" from onOne Software ( http://www.ononesoftware.com/products/perfect-resize/ )  It is part of the Perfect Photo Suite 6.  And they have a trial.

I was rendering out images at 1920 x 1080 and setting them as wallpaper so I could look and critique for a while and then make changes later.  Then I started rendering out at half size (960 x 540) and using Perfect Resize to double the size and didn't lose much image quality (of course it's not "perfect".)  But it sure cuts the render time and may be suitable for a very large final image.

Here's a quick example.  The right side is a portion of a 960x540 render and the left side is a portion of the same image processed by Perfect Resize to 1920 x 1080.
(04Dec20) Ryzen 1800x, 970 EVO 1TB M.2 SSD, Corsair Vengeance 64GB DDR4 3200 Mem,  EVGA GeForce GTX 1080 Ti FTW3 Graphics 457.51 (04Dec20), Win 10 Pro x64, Terragen Pro 4.5.43 Frontier, BenchMark 0:10:02

PCook

Good suggestion jaf and thanks for the image test.

What happens in that type of resizing scenario is that new pixels are generated by inspecting neighboring pixels with the end result being visual fakery. You do lose quality, but not to a significant amount visually because the mind blends it all back together (unless you resize too much). However, you can't do much additional post processing on the such an image, so resizing is best as the last step in the image production. Such resizing has its "up" limits and might do well where your end audience is not critical or the media couldn't have handled the image at its native resolution anyway, such as a newspaper and the Web. The issue is when you need the image to stand up to scrutiny or print at its native resolution. But if there is any chance of additional image processing, resizing "up" tends to get one in trouble. Resizing "down" throws pixels away, which is bad enough. But not as destructive to the image visually. Resizing "up" adds pixels by effectively guessing what the color of the new pixels should be based on surrounding pixels. In short, it comes down to visual fakery. In my case, I require that the image have all of its pixels intact, natively, so that the image can be post processed as/if needed and retains its quality in even the most demanding of image replication and print situations at the image's native size.

-Pat

jaf

I still render my "final" at the target resolution -- just use the resize method to save time.

With my example, I purposely chose a scene I had that used a model with "hard surfaces" that would challenge the resize, to see if it could maintain the edges with the generally soft surfaces of Terragen terrain. 
(04Dec20) Ryzen 1800x, 970 EVO 1TB M.2 SSD, Corsair Vengeance 64GB DDR4 3200 Mem,  EVGA GeForce GTX 1080 Ti FTW3 Graphics 457.51 (04Dec20), Win 10 Pro x64, Terragen Pro 4.5.43 Frontier, BenchMark 0:10:02