-7
$\begingroup$

Viewing a 3d object is considered rendering. Hence, why is there even a "Render Image" option, and why is it so slow on my computer?

--Edit--

Not sure why no one understands the question. Whenever you rotate your 3D model around, that's considered rendering. Hence by that logic the "Render Image" button is worthless.

$\endgroup$
9
  • 1
    $\begingroup$ when you launch a render with the Render button, it will take into account your Sampling > Samples > Preview value, whereas when you work your object on your 3D view, it will take into account your Sampling > Samples > Render value. If you set your Preview value as high as your Render value, it will take as much time to display in your 3D view than if you launched a render with the Render button... $\endgroup$
    – moonboots
    Commented Jun 19, 2019 at 7:28
  • 3
    $\begingroup$ What exactly is the question here? Perhaps the question could be why is rendering so slow? Or how to speed up rendering. Both of which are well covered for each choice of render engine. eg pre 2.8 blender.stackexchange.com/questions/26593/… $\endgroup$
    – batFINGER
    Commented Jun 19, 2019 at 9:21
  • $\begingroup$ @batFINGER Did you not read any of my details? I've clearly explained that it's already rendering in real time, so "Render Image" should be instantaneous. I don't understand where the confusion is coming from. $\endgroup$ Commented Jun 19, 2019 at 16:06
  • $\begingroup$ I don't agree with the premise of your question. IMO You make a weak point. Arguing semantics in that because you define the viewport display as rendering, we should "all see the light brother" and ditch the render button. There's renderin and there's renderin. $\endgroup$
    – batFINGER
    Commented Jun 19, 2019 at 16:39
  • $\begingroup$ @batFINGER I don't know how it's a weak point, as by definition the viewport (if that's what it's called) is the rendered image. In either case, I'm not trying to persuade you to ditch it. I'm asking what's the benefit of using it is. $\endgroup$ Commented Jun 19, 2019 at 16:50

2 Answers 2

3
$\begingroup$

Different use cases call for different performance vs. quality trade-offs.

In the viewport, rendering speed is of prime importance. When you're dragging vertices around, you don't need accurate lightning, or even reflections. What you need is that the vertex position reflects where the cursor is right now rather than where it was six hours ago. Blender lets you go down all the way to wireframe if you really need the frame rate, but usually one uses the OpenGL renderer. Instead of raytracing each pixel, you throw at it a simple math formula that ignores all the surroundings, but it still looks reasonable.

In the final render, you want photorealistic results. To do that, the Cycles renderer computes the color of each pixel separately. That takes time, but it lets you get things like: accurate reflections and refraction, lighting that doesn't go through walls, lighting that bounces off mirrors and even walls, fog... You can tweak that by setting the number of samples. Fewer samples take less time to compute, but the results are noisier. Blender can sorta do that at acceptable speed in the viewport, but it does so at reduced resolution (bigger pixels) and very few samples.

Blender 2.8 introduces the EEVEE renderer. It doesn't quite give you the best of both worlds, but it does look far better than the internal renderer that was in 2.7. But there's stuff that it cannot do. Accurate lighting is a process that really takes time, and there's no way around it. EEVEE lets you compute lighting in advance (very slowly), but that doesn't work if you want to bounce light off of things that keep moving around, and it does need you to set up where the samples should be taken from and at how many. You can fake accurate reflections by rendering the scene from specific points and then querying the renders from each pixel, but that only really works for small things or flat surfaces. And it also needs setting up. It can also raytrace reflections based on what's shown at the screen (much faster than using the scene directly), but that fails when stuff is behind a corner or just outside the viewing cone.

In short:

  • Blender internal works well for modelling, but the results look nowhere near realistic.
  • EEVEE can produce great-looking images really fast, but it can't handle things like dynamically changing global illumination, multiple refraction, or even curved mirrors.
  • Cycles is the main selling point of Blender. It can produce photorealistic images, but it needs the time to do so.

  • In the viewport, you want speed. Cycles is bad at doing things fast.
  • In the final render (which is what the render image command is for), you want things to look perfect. And that takes time. You can configure Blender to use EEVEE for the final render - to cut down the rendering time at the expense of accuracy - but if you can spare a few minutes of waiting, you can get a still image that looks better than what even EEVEE can produce, and then - when you're ready to generate the data that you really need to be perfect, increase the number of samples even higher and then give it the time it needs.
$\endgroup$
1
1
$\begingroup$

Your question doesn't give us much detail to help us understand. What engine are you using? Cycles or Eevee? Are you referring to the OpenGL render? What does your scene look like? Does it have lots of geometry? Do the objects have many modifiers?

If you're talking about Cycles or Eevee (my guess), there's separate settings for the preview versus the render: samples, bounces, subdivision levels, etc. Your render settings may be much higher than you thought, or at least what your computer can take. Just simply lower those settings to get faster results. Also, your preview tends to be a much lower resolution than the final render, especially if you're using the render border tool. Another thing to check is, under the performance panel of the Cycles render settings, is the tile size. If you're using your GPU, try to make that a big number (512x512 or a multiple of that). If you're using a CPU, make that smaller. This impacts the memory used per tile, which will make a big difference in render times. For the 3D window, it usually preview renders as one big tile, which can make it quick or slow, depending on your scene.

For an OpenGL render, it in effect does a screenshot, but it still has to redraw all the geometry. If that's slow for you, but the preview isn't, then that may be a concern.

Overall, please be more specific in your question, and you'll get a more specific answer.

$\endgroup$
0

Not the answer you're looking for? Browse other questions tagged .