Quote from: Oshyan on November 07, 2009, 10:47:31 PM
This is actually a very commonly requested feature. Unfortunately it's not nearly as simple to implement as it might seem. As a matter of fact the majority of render engines don't have this feature, even high-end professional systems like Vray or Mental Ray. There are of course some renderers that do allow this, but it would require a good amount of development time. We do have hopes to include it in the future, but for the moment it is not a focus of development.
If you're having problems rendering an image due to crashes, power outages, etc. I suggest trying to render in crops, which will finish sooner and thus save your "progress". You can then stitch the crops together later, though this is of course an added step. It's the best solution for now...
- Oshyan
Thanks for letting us know you are considering it. I understand that it takes some programming effort to rebuild what's in memory easily and quickly restart the render. But, with disk space amounts being readily available, the easy approach would be to create a scratch disk and write the rendered data to the scratch disk at periodic intervals. This at least gets you back to the image where you were (and possibly even the rendering engine's most recent state). Even if you only write the scratch disk every 15 minutes, that means you only lose at most 15 minutes of render time. That's far better than 48 hours lost.
I also understand that most renderers don't offer this option, but that's because they offer other compensation for this feature lack. However, just because other rendering engines doesn't offer it doesn't mean it isn't a valid request. Large commercial apps, however, replace that feature with network rendering. So, Vray and Mental Ray and even Carrara offer network rendering processes to compensate for the lack of resume. So, while you cannot easily resume one machine that might crash, you may still have 4 other systems rendering so the work isn't 100% lost. Basically, I'm talking about rendundancy vs resuming. Since TG2 doesn't offer any redundancy options (such as network rendering), the only other option is to go with a resume feature. Of course, you don't need to go with a resume feature if you decide to add network rendering (which may be the better option). The only reason I suggest resume over network rendering is the amount of synchronization necessary to get all of the network renderers on the same page. Resume only requires one machine to be synchronized. In other words, I would think implementing network rendering would be far more difficult than writing a scratch disk with some internal data structures for resume.
As far as crops, I've been there and done that. My problem with rendering crops is that there is still an issue with mismatch coloration on crops. It seems that the GI changes for each calculated crop section, so the overall coloration of individual crops don't match. When you stitch them together, the colors don't always match up and that requires a lot of time doing color correction matching on each crop in postwork. On top of that, since color matching isn't always perfect, it requires additional hand clone-tool touch up in the Gimp. For right now, rendering the image all at once saves that time with postwork.
Thanks.
--
Brian