Idea for "The renderer that keeps on rendering" in

[Kram1032]

Since there is .igi, renders can be resumed, after stopping them.

Can this be used for animations too?

Just like:
frame 1 -> 100 spp
frame 2 -> 100 spp
...
frame n -> 100 spp
last frame -> 100 spp

resume frame 1 -> 200 spp
...

and so on.
If that's possible, "The renderer that keeps on rendering" also is true for animation

What would you say, Nick?

[suvakas]

Can you tell a real life situation when you would actually use this?

[mrCarnivore]

Oh no, a suggestion.

Don't let Deus see this. He will jump right on it and will not leave you alone until he has shown everyone how stupid you and your idea are!

EDIT: To your idea, if anyone would really use indigo for rendering animations this could become quite useful and would be the logical extension of the indigo idea, I think.
Having said that, I think implementing this idea is really low priority (for me at least), since there are a lot of more important single frame features missing, yet. Like bumpmapping of blended objects...

[Kram1032]

? I don't get, what you mean...
It's not an improvement of any picture related stuff....
It just would get the animation much clearer, or as clear, as you want it to be....

Previews also would be better possible, this way, I guess...
If you can see, there is something inexpected, just stop rendering and change it. In an animation, that just keeps rendering for, say 5 minutes per image (= 12 images per hour => very short anim after a whole hour), the anim isn't quite clear....

[suvakas]

I think most needed feature for animation rendering is the possibility to specify the amount of samples that has to be reached for each frame.

[suvakas]

If you can see, there is something inexpected, just stop rendering and change it.

Now how can you later resume it when you change something?

[edit] You can render a fast animation preview by using short rendering time for each frame (or you would use low amount of samples when this feature would be available).

[Kram1032]

These two can be combined quite good^^

some stuff, like:

- render until x spp
- render until escape (add save exit )
> additional: don't use 100 spp, before jumping to next frame, but x spp

@mrCarnivore:
That's why it's just an idea and not a request I'm not animating even in faster, biased renderers

But some users already did this and I don't think, it's too hard to implent

[mrCarnivore]

I think most needed feature for animation rendering is the possibility to specify the amount of samples that has to be reached for each frame.

Exactly that would be solved by Krams approach. You can just let it render for as long as you want to and whenever you reached a satisfactory level of noise you let the animation render finish the last frame and then stop.

With your approach you will have to guess the number of satisfactory samples and if it is not sufficient you have to render everything again.

[suvakas]

With your approach you will have to guess the number of satisfactory samples and if it is not sufficient you have to render everything again.

Gotcha! Point taken.

[Kram1032]

xD
Just noticed, that the headline isn't saved completely...

It was ""The renderer that keeps on rendering" in Animations"

I didn't know, that my idea was written that unclear... I thought, it was clear...

@ mrCarnivore: thanks for clearify my idea

[CTZn]

With your approach you will have to guess the number of satisfactory samples and if it is not sufficient you have to render everything again.

Gotcha! Point taken.

Yes but no

Counting sample would ensure a certain coherency between the frames, you don't want all the time your animation to look like ealy 1900's. IMHO controlling quality makes more sense than controlling time of execution. halt_time has some usages, halt_samples would be perfect.

And it has much more applications than animation, I'm a wild defender of that feature it's required to compare the performances of different settings and such research about their optimisation (I believe at least).

[mrCarnivore]

I have said before, that I don't think improving animation support in indigo should be priority. There are lots of other signle frame features that need to be implemented before that.
Halt_samples would be a nice thing and better thatn halt_time, I agree!

But when we are talking about animations right now, I must say that Krams approach is still a nice and consistent idea.

[mrCarnivore]

i guess when halt_samples gets added,
one could easily write a script or wrapper to automate this whole procedure.

it need not be coded into the engine itself...

You are right, it should be possible to render halt_samples for one frame then mmove on to the next and after the last frame resume the first one for halt_samples... This would still let indigo "keep on rendering" and would not be needed to be coded into the engine.

[Deus]

You are a funny guy carnivore. First you bash me then you use my standard argument against another person. This idea however is pretty good. That you can get an animation progressively better. I like it but as mrCarnivore says there are alot of single frame features I'd like before this

[Kram1032]

O.o
OMG!!!!!!!!!!!

Deus? Are you ill? Do you need some medicine?

I finally found something, that you find USEFUL!!!!!!!!!!

Yes, I already said this:
It's not a request, but an idea!

I myself will need it hardly ever, but I think it should be quite easy to implent this...

Anyway: It's definately low prior.
Single-Frame-Render-improvements (would be a very long word in german ) are high prior to this...