Request for Indigo 4

[Originalplan®]

Hey Guys. Im new here so first of all Hello everyone.
I found Indigo around 2009 and it was a love @ first click.

So Indigo 4 is around the corner and i just want to submit a feature request real quick.
One thing that i think could be really usefull is a RESUME render function.
Like : You render a scene till it reaches xyz samplerate/time and then you can either save it or HIT RESUME and specify a new target range : xyz (2) samplerate/time " naturally this new rate cant be smaller then the already completed job " .
So this way Indigo does not have to begin again rendering every time.
This feature would make sense to me...but maybe not others.

Anyway let me know.

Thanks!

®

[Zom-B]

This is available in Indigo since v2 I think ^^

[Originalplan®]

Hmmm....it begins rendering from start by me every time.
Does not matter if i use the standalone Indigo or the plug.
Did i mess up some prefs you think?
Cuz when i hit pause on the standalone Indigo and then resume it calculates the image again from start.

[Oscar J]

No it isn't Zom-B. You can't resume a stopped render directly without saving and resuming the IGI.

[Zom-B]

Maybe I was focusing my attention on this sentence to much:

So this way Indigo does not have to begin again rendering every time.

Yes, IGI saving is needed to resuming!
But I also don't see a point to have some halt condition for a rendering while you are on the computer, why stop automatically and not keep going until the user tells so?

[Originalplan®]

I think it would be more simple than setting either an unrealistic amount of samplerate/time or say stoping and saving IGI @ a certain time then loading it up and resuming the render.
It would just make a more responsive workflow i think.

[Polinalkrimizei]

Sometimes I have to stop a heavy render to free some system resources to do something else, so for me easily resuming a render makes sense!
The only question is how to do it without cluttering your HD with .igi's? Each may take up some gigs depending on resolution...

[thesquirell]

Current workflow makes pretty much sense to me. If you want to resume your render, you need to have some information to give to your renderer, so it can continue. That information is stored within IGI. Unrealistic high sample rate/hour is not needed at all, just use infinite time and stop whenever you are satisfied. Currently, I am more worried about sampling in animation, and the need to extra sample some parts, for example, dark corners, without the need to sacrifice resources onto the whole scene, but instead focusing them to just one spot/spots.

" You can't resume a stopped render directly without saving and resuming the IGI".

This problem could be solved by creating a function that automatically saves IGI file to the root/specified directory, in specified intervals(sampling rate percentage, or time interval). A function that can be turned on/off, much like auto-save in other applications. Something like "Auto-save IGI"( on/off), every (ssp/time condition).

To be honest, I never used sampling rate halt condition, so I never tried doing something like achieving specified sampling rate, then trying to continue on that level to get more sampling - pushing the condition further, upon reaching it. Do not know if that is even possible atm, maybe by going into the IGS file and changing conditions:
<halt_time>-1</halt_time>
<halt_samples_per_pixel>-1</halt_samples_per_pixel>
<frame_upload_period>40</frame_upload_period>
then resuming with IGI. The requested feature, if I am not mistaken, is to Indigo asks the user if the user wants to push/change halt conditions upon reaching them, and then automatically making the change in the IGS file. If so, would love to see it.

[Oscar J]

I don't think you guys are getting his question.

He simply wants to resume the rendering of the scene after it's been stopped. Currently, if you hit the stop button, you can't resume the render without first saving and loading the .igi file, which is really weird. Since you already have the igi loaded in the RAM anyway (unless you close the scene/application) there shouldn't be anything stopping Indigo from continuing working on the IGI.

[thesquirell]

This "stopped" state in Indigo can be achieved by two ways. One is to stop it by yourself, the other is to reach halt condition. Resuming render after reaching halt condition, without having to change IGS makes no sense, because your scene is rendered, those were the conditions. Resuming it would mean to start it all over again, since it is already finished. The first case is basically clicking stop by mistake, instead of pause/render. Either way, I totally agree. You should be able to further sample your scene, without having to mess around with IGS file, regardless of case.

[Zom-B]

in v4 the stop key is already gone, only option is to pause the render (or reach halt condition!)

[Originalplan®]

@Oscar J Yepp your getting my point. @thesquirell your too...but more technicaly.

Current workflow makes pretty much sense to me. If you want to resume your render, you need to have some information to give to your renderer, so it can continue. That information is stored within IGI. Unrealistic high sample rate/hour is not needed at all, just use infinite time and stop whenever you are satisfied. Currently, I am more worried about sampling in animation, and the need to extra sample some parts, for example, dark corners, without the need to sacrifice resources onto the whole scene, but instead focusing them to just one spot/spots.

Makes sense to me too.Thats not the point. In my case rendering to a certain samplerate like (ssp:400/-1time with GPU) makes more sense in prototyping and animation then using (ssp:-1/-1time). So the resume render option as Oscar J explained, would make sense in this case if you wanted to just quickly check out a frame or still with (ssp:700or1000) to get a final(ish) look. But its a special case...and i think of it more like a DPI thing and not actuall resolution. For example if you render out a loop in 800x800 for a .GIF or vid you don't need really high resolution, but you still have to define a minimum samplerate, just to get good lights and shadows. And because each project is diffrent you cant really have a standard ssp...and here is where the resume render option would come in, whit no save out and read in.

As for the >

I am more worried about sampling in animation, and the need to extra sample some parts, for example, dark corners, without the need to sacrifice resources onto the whole scene, but instead focusing them to just one spot/spots.

I think a HDRI style approach would handle this is animation. So lets say you have your moving object in the middle and you render it out with foreground Alpha. Then you could render the background with (X_HDRI_option). So (X_HDRI_option) would take your background (All or the areas specified by the user) and would 50% - 50% it. So it would create two renders instead of one from the background ( 50% of specified ssp for each ) one slightly brighter and one a bit contrasty ( Like realworld HDRI photography ) in this way blacked out corners would disappear. Even very bright burnt out tones could be fixed this way. And you could handle the rest of color grading in a thirdparty app. But hey its just an idea...

@Oscar J Yes data is in the RAM anyway....so thats why i don't get it. And made this request. I get that the IGI is needed for the ACTUALL scene and models and its good that way.But Indigo has a cache folder.So it could manage IGI's as cache too. So IGI temp cache would be created in a specified folder / user defined ssp or time rate. And when you manually save out the IGI than it would work like now and all cache would be deleted.

@Zom-B Cant wait for 4 double GPU support will be a big step forward.

PS: Thank guys for all the comments!Its good to be here

[Oscar J]

As Zom-B mentioned (leaked? ), this problem is should be solved in version 4.

[zeitmeister]

I agree with Originalplan.
Resuming an igq with higher samples is what I needed for my latest commercial car animation.


Cheers, zeiti

[zeitmeister]

Another request:
A normal pass would be very nice.
And by the way: is multipass rendering an option? Splitted by threads? That would be sooo cool.


Cheers, zeiti