7
$\begingroup$

What I tried:

  • Most available tutorials
  • Some render / file format settings

The result: A 2 minutes long animation that plays fine in realtime takes a day or two to render on a GTX 1080.

There's no button to just "play out to a file".

My question is not "how", cause obviously there's no way right now. The question is: is it on the roadmap and will it come with the release of 2.80?

EDIT: Question was misunderstood - I have a complex scene in Eevee (not the default cube). It looks awesome and plays at close to 60FPS inside Blender. So if I would grab it with say an external video recorder, my scene "render" would be finished in 2 minutes (or as long as it plays). But using Blender's "render animation", still with Eevee and the same settings as the realtime window, it takes a day to render out to files. Can't I just "play it out"?

Improve this question
$\endgroup$
2
  • 1
    $\begingroup$ I didn't try blender 2.8 yet, but for 2.79 and older versions there was always a button that rendered the things shown in the viewport to a file. I think it was called OpenGL Render Viewport Animation or something along those lines $\endgroup$ – HenrikD Dec 8 '18 at 11:27
  • $\begingroup$ Questions like this are opinion based and will therefore likely be closed unless they are in the form of "how can I currently do this?" $\endgroup$ – Ray Mairlot Feb 9 '19 at 15:45
9
$\begingroup$

I think what you are looking for is this!

Improve this answer
$\endgroup$
5
  • $\begingroup$ Thanks - I don't mean to demotivate anyone but sadly this isn't the answer yet. It works but does the same as the "render animation" button, meaning it still takes hours to render out a realtime animation that plays fine in the viewport. And your option also blocks the UI while rendering. Guess I'll have to wait or just use some desktop video recording. $\endgroup$ – bortran Dec 18 '18 at 17:14
  • $\begingroup$ Hm. No, it actually does not the same as render animation. It takes screenshots from the viewport while "render animation" does higher sampling with a few passes and caching geometry before it starts to render. Well it doesn't render real realtime because of extra anti aliasing but actually it should be fast enough so it would render about 5 minutes for a 2 min animation instead of hours. Maybe it would be great to have a look at your scene so we can spot this issue. $\endgroup$ – Jerry Yeung Dec 20 '18 at 8:47
  • $\begingroup$ Oh I just read another answer from you below. So never mind. I just tried it by myself with a complex scene with about 7 millions of triangles and full shaded. It renders 1 sek per frame. This obiously not fast enough for your needs. $\endgroup$ – Jerry Yeung Dec 20 '18 at 9:06
  • $\begingroup$ This was exactly what I needed thanks! Still not AS fast as the viewport itself, but way faster than the normal render :-D $\endgroup$ – BaronVonKaneHoffen Mar 14 '19 at 9:56
  • $\begingroup$ @JerryYeung at the time I tried this I didn't realize it's working in a different way, bit of Blender beta-version chaos was involved on my part, please don't mind. $\endgroup$ – bortran Mar 24 '19 at 23:07
2
$\begingroup$

A few words about "real-time engines":

Understand that even though it's a "real-time rendering engine", the render times depend on your scene. With such render engines, you can optimize your scene like a video game until it reaches 16ms/frame to render. Actually, it's not that you can. You have to work your scene for it to be renderable in real time. The same ways we make video games.
But for more complex scenes, it will take more time. It will still be insanely faster than a raytraced render like does engines like Cycles, but it might not be watchable while rendering.

And as optimizing a scene is an insane's job, most of the time you will skip that and do your renders with a few seconds/frame.

As an example, take Unreal Engine or any modern game engine: you can have actual real-time with insanely high fps (well, it's their first job anyway). But when people make movies with it, suddenly it takes more time per frame. Seconds, minutes, ... Because they free themselves from the optimization, they allow themselves to do higher quality assets and render settings, they make less use of repetitive content, etc...

Now, about EEVEE, clearly it's not finished yet, it does take a significant time even to render a still animation of the default cube. Hopefully, it will be enhanced throughout the years. Maybe this will be the base of the future interactive mode, maybe we could make actual video games in the future as we did with the Blender Game Engine. But really, "real-time engine" doesn't mean it renders in real time anything you throw at it. And when you have the possibility to make an awesome render with the only price of a few seconds of render time per frame, usually you go for it, unless you have a technical need to render dozens of frames per second.

Improve this answer
$\endgroup$
2
$\begingroup$

If I understand you correctly, the question is why it renders slower than it plays back when the render is the same image like the viewport. That could have a number of reasons:

I'd compare this to the (much more stable) opengl render option from 2.7: It also renders exactly what the viewport sees and still doesn't achieve the same framerate, probably a second or less per frame. The reason for that is that it is making an image out of every frame, it needs to store the data. Displaying a frame takes much less resources than saving it to your harddrive.

The second thing is: Have you ever noticed that things like subsurface scattering in eevee tend to look a little weird while moving the viewport around? The reason for that is that it only renders lower quality reflections etc when moving it around. And then it starts to render better versions when the viewport stays still for a while (a little bit like the cycles preview). With a complex scene it will start to "downgrade" more materials while moving the viewport. When you render the animation out, it calculates high quality reflections every frame which takes much longer. That's why the viewport appears so much faster.

Depending on the length of your animation, the few seconds more per frame might add up. Just "playing out the animation" might be possible by just lowering the quality if that's what you want. Plus the processing after rendering the image might be badly optimized, you just don't realize it when using cycles because it takes long anyway. But rendering it in the exact same time as the playback is physically impossible as it needs to do more processing.

Improve this answer
$\endgroup$
1
  • $\begingroup$ As I said: "..still with Eevee and the same settings as the realtime window.." - I took care of that, cause I know the settings can differ. But again, this is more of a methodological problem of Blender, if it writes out single .PNGs that alone can be the reason for it to be slow af. Blender should make an "animation dumb" and I wanted to know if Blender Devs are aware of this and if it's maybe on the Roadmap already. $\endgroup$ – bortran Dec 9 '18 at 17:23
0
$\begingroup$

If the Turing architecture for NVIDIA's recent RTX GPUs, maybe. It would specifically need to be downgraded in terms of demand to real-time render with rays. Obviously in order to get to movie level visuals, it would be better to actually render in non-real-time.

But I assume that old videos such as Big Buck Bunny could be rendered very close to real-time on a RTX Titan.

Improve this answer
$\endgroup$

Not the answer you're looking for? Browse other questions tagged or ask your own question.