I just tried rendering a huge image.
By huge I mean 60000 x 9000 px!
(It's a lobby poster commision ... )
I made a 2835 x2835 px crop of the centre of the image (works out as a meter square printed at 72dpi) to test if the res was going to be ok and the render completed fine but refused to actually finnish. The preview refreshed (which is always paused when Terragen is rendering) so the render must have finnished in some way, but the button never changed from "Pause" to "Save".
I tried rendering the same image to disk and got the same result. Nothing saved and the render just sort of continuing, clock ticking etc.
Looks like I'm probably going to have to render in sections and stitch together ... but I'd like to avoid that if possible.
Cheers
How about a render farm?
I don't think that would help especially. The render has finnished but not "released". I suspect a farm would have the same isssues.
Did you render your museum wall images in a single pass or break them down into sections?
Cheers
There is a command line option -cropoutput which tells Terragen to only create an image the size of the crop, without the surrounding black pixels. If the renderer is having trouble with the size of the full image regardless of crop size, this option might help.
Matt
That worked, thanks Matt.
I would guess, given the behavior you describe, that it's one of the post processing effects that is having trouble applying itself to such a large image. I think the basic render process is capable of rendering at that resolution, but the post effects probably aren't designed to do so. This would include GISD, by the way.
I would also note that at very high resolutions your pixels-to-scene-area ratio is going to be much higher and thus, I think, the GI should be more accurate than at a lower resolution *even with lower settings*. Since you are looking at a potentially massive GI cache (generated at render-time even if not cached to disk), consider using low (e.g. default 2/2) GI detail settings, or perhaps even rendering a GI cache for a lower resolution image and using that on the higher resolution final render.
My final thought is to wonder whether the image load/save libraries we use are actually capable of writing files with e.g. a 60k pixel width. This I don't know. I'll try to test it with a simple scene with no GISD or other post effects. See if I can get it to complete, and then, to save...
- Oshyan
Thanks Oshyan, I did wonder if it might have been some of the post process effects particularly the image pass (I guess that is GISD, yes?).
I wouldn't even attempt a scene at this res fully populated, that surly will have to be rendered in tiles.
I did notice when I created a sample file in photoshop at 60K that it warned me of problems loading and saving in some (undefined) programs.
I'm rendering at 6k now and I'll try a few crops at 60 with the command line renderer and if that works then it should be achievable ...
I am doing a test now in the GUI and so far I'm at 55GB of RAM used with the GI prepass about 3/4 complete! This is just the default scene, detail 0.1, AA 2, and 60k by 6k render resolution, with GISD, AA bloom, motion blur, and any other post effects disabled. I just want to see if I can even finish the render and save it. I'll let you know. But it's clear that even if you could, the memory requirements for such a render are going to be massive with anything but a simple scene and low render settings.
- Oshyan
Quote from: cyphyr on February 24, 2017, 04:48:29 PM
I'll try a few crops at 60 with the command line renderer and if that works then it should be achievable ...
You can also use the
-cropoutput option with the GUI. It affects all images rendered and saved within the GUI too. You might want to create a shortcut to run with this option.
Matt
The museum files weren't that huge, they were rendered in chunks of maybe 16000x3000 and stitched together. And there was no GISD then. I have to do a biggie again, so this is interesting.
Follow-up on this, memory use peaked at 60GB *during the GI prepass*, but was only at 30GB (peak) during final render. The render finished in approximately 1.5hrs, on a 16 core (32 thread) Xeon machine (in the top 10 on the TG benchmark list). I had all post effects turned off but even still it took several minutes at the end to complete, even after the rendering process seemed to be done, and the render clock was stopped during this time (presumably antialiasing sample reconstruction phase?), and then it took a minute to actually save it as well once I went to do so. The resulting file in compressed TIFF was 375MB or so.
- Oshyan
Thanks for checking up on this. Good to know it works on a high end system. Mine's good but not that good! ;)
I think I'll be going the -cropoutput route though with an animated sequence of crops.
Another thing to bare in mind is the image size is actually 116000 x 6840 now so EVEN BIGGER!! Is this a reccord !? ?!
I'm not doing a GI Cache but I do have GI pree pass padding at 0.5 and thus far the tiles have been seamless.
It's a very quick turn arround job so I'll keep you informed.
Glad to hear it's going well, and I agree -cropoutput is the way to go. Are you able to say what the job is for? That's quite an image size indeed. :D
- Oshyan
Can anyone explain how exactly you setup the _cropoutput renders? Never worked from the command line, but I understand it's also possible from within TG?
It's not as daunting as it seems at first. Take a good look at the "win_command_line.txt" and try some small tests.
This is the one I used ...
"C:\Program Files\Planetside Software\Terragen 4\tgdcli" -p E:\Projects\Test.tgd -hide -exit -r -f 1,2,3,4,5 -cropoutput
Teake care of the exact syntax, quotes, spaces and hyphens...
Rendered and saver frames 1 to 5 to the location set in the tgd file.
How this is done from with the Terragen UI I have no idea. Really there should be a button!
Thanks Richard. Button for sure!
I believe Matt is talking about actually starting the Terragen application with the -cropoutput "flag" or "commandline argument". You can add it by creating a shortcut to tgd.exe or tgdcli.exe and in the shortcut properties, you just add the -cropoutput after the executable name (outside of the quotes) in the "target" field.
- Oshyan
It would be useful to have a crop option that rendered the crop region blown up to the render size defined in the render node, as this would provide a means of zooming in on the detail in a region without having to render a very large image most of which is black pixels.
For example if the render node image width was 800 and the image heigh 450 then with a crop size of (0, 0.25, 0, 0.25) the render would be zoomed or blown up so that the crop region was effectively that from an image size of 3200 x 1800.
I hope that makes sense.
But that would mean that the crop ratio needs to be similar to the render ratio, I'd say. And it needs to be very clear in a prerender tab, or you might end up with huge render(times).
If you do a series of frames of croprenders (with _cropoutput working), would you need to use a GIcache? I guess that would be best, or it would calculate a new GI for every crop, which may not stitch together nicely. And I also guess that if you use a GIcache, you don't really need overlap, but crops will fit pixel to pixel (if you sue nicely divided crops of course).
And what about the post stuff like GISD and lens artifacts, will they fit together nicely?
The shortcut addition works fine, btw, so thanks Oshyan.