Terragen Pause/Save Funciton??

Started by masonspappy, February 01, 2016, 08:19:18 AM

Previous topic - Next topic

bobbystahr

#15
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.
something borrowed,
something Blue.
Ring out the Old.
Bring in the New
Bobby Stahr, Paracosmologist

masonspappy

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%.

masonspappy

Finished last render at 16 hrs 14 mins.



Dune

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.

rajm

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

masonspappy

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). 

Dune

The only problem with a combined stopped render, rajm, is that you miss the GISD.

masonspappy

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?

Tangled-Universe

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.

bla bla 2

There especially for water or is it too long rendering.

Oshyan

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

bobbystahr

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.
something borrowed,
something Blue.
Ring out the Old.
Bring in the New
Bobby Stahr, Paracosmologist

Dune

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.

bobbystahr

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.
something borrowed,
something Blue.
Ring out the Old.
Bring in the New
Bobby Stahr, Paracosmologist

masonspappy

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?