I would like to be able to pause and save an incomplete render and then close Terragen completely. Then at a later time I would open Terragen and resume the render.
Is this possible? The idea is to close TG3 and use my PC for something else without loosing what I've rendered so far.
Quote from: masonspappy on February 01, 2016, 08:19:18 AM
I would like to be able to pause and save an incomplete render and then close Terragen completely. Then at a later time I would open Terragen and resume the render.
Is this possible? The idea is to close TG3 and use my PC for something else without loosing what I've rendered so far.
I've often wished for that as I do actual work on my one confuser, the pre intel mac I own is useless for art with only 2.5 G RAM.
Where, then must be left the rendering what to do in the day when you do not hit the pc.
Quote from: masonspappy on February 01, 2016, 08:19:18 AM
I would like to be able to pause and save an incomplete render and then close Terragen completely. Then at a later time I would open Terragen and resume the render.
Is this possible? The idea is to close TG3 and use my PC for something else without loosing what I've rendered so far.
That would be an awesome feature. Like when u save your game and next time just continue from there....
The best thing you can do so far is:
1) Write out a GI cache and by using that cache for rendering it allows you to render crops at separate times, without having differences in lighting.
However, you need to have a bit of an idea how long a crop would take.
2) Hit pause, do whatever you like using your PC for and hibernate.
thanks TU. Will definitely need some kind of new approach to rendering. Currently rendering a 1920x1080 image on an I7-5820K (6 core/12 thread) 32 GB memory and used only as a rendering and modeling machine. current render time (so Far): 22 hours, 10 minutes with about 15% more image still to be rendered. Going through my settings several times but can't figure out why this would be taking so long. :(
I'll also vote for that..........be sure you post the pic when finished. I want to see the scene that takes that long on that rig. :o
Quote from: masonspappy on February 01, 2016, 10:14:58 PM
thanks TU. Will definitely need some kind of new approach to rendering. Currently rendering a 1920x1080 image on an I7-5820K (6 core/12 thread) 32 GB memory and used only as a rendering and modeling machine. current render time (so Far): 22 hours, 10 minutes with about 15% more image still to be rendered. Going through my settings several times but can't figure out why this would be taking so long. :(
Perhaps you miss something?
Can you copy/paste the render node below?
Also settings for atmo, cloud and lighting are useful to know.
That is horribly long indeed! Rough fine displacement, especially in water or (smoothed) RT reflections, huge clouds, very dense vegetation with lots of alpha computing, soft shadows, and more than one compute terrain take the most. If ever possible, I try not to use a compute terrain.
Quote from: Dune on February 02, 2016, 03:01:23 AM
That is horribly long indeed! Rough fine displacement, especially in water or (smoothed) RT reflections, huge clouds, very dense vegetation with lots of alpha computing, soft shadows, and more than one compute terrain take the most. If ever possible, I try not to use a compute terrain.
Indeed, sounds like he's using my crappy old dual core with 8G RAM...On the upside I don't feel so bad about the 22+ hours on my Moon Bridge scene.
Not sure, might have figured out the problem. Testing now to see if it's fixed.
Attached image is downsized from original 1920x1080 render at default settings detail:5, AA:3, 1/4 sample, cache detail: 2, cache quality:2, max threads:64, buckets:256, Subdiv cache 1400. 23 min 19sec render time seems reasonable to me. Now I'm testing same size render at higher resolution to see what render time is.
I cancelled the original render after it ran 34+ hours :o and was only 95% done. looking at rendered node, noticed detail and AA were 8, threads were 128, buckets were 512MB, subdiv cache 2600 in the offending render node. the tgd is one I reused from another project about 2 years back, and had several render nodes set up in it. I may have screwed it up then and did not think of it when starting this render. Hopefully will have proof tomorrow morning that issue is fixed.
now that is a very nice scene! :)
Beautiful scene. Just a thought. If the house has an interior and you wish it to show through the windows, the window glass has to be loaded separately from the building and set to not cast shadows to get glass to work.
latest render looks promising so far. Thanks TU and Dune for your comments, I think that helped me narrow down my search for wonky parameters. I'm guessing latest render is going to run abt 14 hours - doesn't seem to be choking in specific areas as previously.
@Bobbystahr: re: glass shader and casting shadows, are your referring to setting the sunlight to not cast shadows?
Rendering save/resume is something we've had requested a number of times before. It's not that easy to implement, unfortunately (we would need to save the entire render state and memory to disk, sometimes many GB of data, among other things). But I agree it would be nice if it's possible in the future.
- Oshyan
Quote from: masonspappy on February 03, 2016, 04:02:16 PM
latest render looks promising so far. Thanks TU and Dune for your comments, I think that helped me narrow down my search for wonky parameters. I'm guessing latest render is going to run abt 14 hours - doesn't seem to be choking in specific areas as previously.
@Bobbystahr: re: glass shader and casting shadows, are your referring to setting the sunlight to not cast shadows?
No, only the glass objects. That's why they should be separated out and loaded separate from the house which requires shadows. It
can be done in the Parts shader in the internal network. Load the same model twice and append it's name with windows on the first one. In it's Parts shader dial all items except the Glass to 0 or Black in the opacity tab and replace the windows objects Default shader with a Glass shader ... and in the other model just do that to the windows minus the glass shader, and remember to turn off cast shadows on the house_windows.
Well, that image is still rendering. 15 hrs, 16 minutes so far. About 98% complete.
But I'm having a 'WTH???" moment.
According to Task Manger, only 3 of the 12 total cores are being utilized(!) That makes me think the PC is automatically throttling back the process load, probably due to heat buildup. I've opened the case and set an external fan (with an Ice pack leaning against it) to blow onto the CPU and water cooler.
I'm pretty sure this is not normal behavior as I periodically check task manger during other renders and always see all cores running at/near 100%.
Finished last render at 16 hrs 14 mins.
Well, no wonder the renders are slow, even 14 hours is very long, isn't it? Depending on your specs of course. So you might best check your hardware with some app.
My workaround for save/resume is to stop the render and save the partial image then on restarting TG I use crop to produce an slightly overlapping image and then when that's complete I use hugin or gimp to stitch the two images together
Quote from: rajm on February 04, 2016, 05:48:31 AM
My workaround for save/resume is to stop the render and save the partial image then on restarting TG I use crop to produce an slightly overlapping image and then when that's complete I use hugin or gimp to stitch the two images together
I did this last night and used PSP to merge the images and result looked fine. :) Thanks!
So this morning I've cropped out the image area that was so slow to complete rendering, and monitoring cores on a second monitor. All 12 cores are banging away at 100%. CPU max frequency is 102% (apparently the tech guys at HP factory overclocked this rig a bit). Memory usage is still abt 30%. Next step is to find a way to monitor core temperatures while rendering and if temp is indeed going too high then will have to invest in a heavier duty cooler (the one I've got is already water cooled).
The only problem with a combined stopped render, rajm, is that you miss the GISD.
Quote from: Dune on February 04, 2016, 08:31:29 AM
The only problem with a combined stopped render, rajm, is that you miss the GISD.
What do you mean?
Quote from: Dune on February 04, 2016, 08:31:29 AM
The only problem with a combined stopped render, rajm, is that you miss the GISD.
Indeed, but you would miss the
final pass of GISD.
As soon as you enable GISD already GISD-like things happen to your render before it's finished and before the final pass of GISD is applied.
A little detail, that's it.
There especially for water or is it too long rendering.
If you are near the end of a render and you only have a couple render tiles/buckets remaining, you can often get less than 100% CPU usage because TG uses 1 thread per bucket and doesn't currently have a "split" function for buckets to automatically divide the workload near the end of a render. In most cases this doesn't make a huge difference to total render time but occasionally you have very tough buckets that are right near the end...
- Oshyan
Quote from: Oshyan on February 04, 2016, 03:36:01 PM
but occasionally you have very tough buckets that are right near the end...
- Oshyan
I can vouch for that as in my interior render with all the windows and glass/water objects///44 hrs and the last 18 were on 2 sq inches on my screen....I think 8 glass objects, 2 with water in 'em as they came with a solid water object.
About a year or so ago I was experimenting and found that a crop render of the last (slow) area was much faster than that same final area being calculated in the main total render. But that was before GISD was implemented, so I don't use that method anymore.
Quote from: Dune on February 05, 2016, 04:15:26 AM
About a year or so ago I was experimenting and found that a crop render of the last (slow) area was much faster than that same final area being calculated in the main total render. But that was before GISD was implemented, so I don't use that method anymore.
That 44 hr render was before GISD...wish I'd know that then.
Quote from: Oshyan on February 04, 2016, 03:36:01 PM
If you are near the end of a render and you only have a couple render tiles/buckets remaining, you can often get less than 100% CPU usage because TG uses 1 thread per bucket and doesn't currently have a "split" function for buckets to automatically divide the workload near the end of a render. In most cases this doesn't make a huge difference to total render time but occasionally you have very tough buckets that are right near the end...
- Oshyan
Oshyan, that 'split' function was exactly what I thought would be happening, but now see that it doesn't. So instead of the other cores pitching in to render what was remaining in the image (once my buckets numbered less than 12, which is the # of threads I've also got available) what was really happening was that threads were being idled as each bucket under the 12-count was completed. I could see the active cores drop from 4 to 3, to 2 and finally 1.
So, would it be of any benefit to decease the bucket sizes to something less than the default 256 MB? Or am I creating other problems for myself?
Decreasing bucket size *can* help in some cases, but don't decrease it too much or you lose efficiency and can even cause some cross-bucket errors. 128 can work fine usually.
- Oshyan