In blender 2.49 there was a down and drity way of rendering out an animation sequence with audio by making the output FFMpeg and then control clicking the little landscape pic in the corner of a window.
This would render the animation with audio but without textures and full lighting effects. It was a great way to render out some sequences quickly in order to edit them together and see how your film was timing out. I also used it to see how an animation looked with lip-sync. It really cut down on render times when you just need a quick play-blast of a sequence.
My question is this: is there anything comparable to this using 2.57b? I really liked using this in order to put together a rough cut of my animation as I worked through a project.
In the 3D Window menu bar, at the far right, are two OpenGL preview buttons, a camera for a still and a clapboard for a movie. But be aware that there are issues with this in 2.57 (they’re on the “to-do” list) that can make it non-functional for some older video cards, and in others, the output can only be in sizes with 256 or 512 pixel increments. IIRC you can do them through the Active camera but not retain the image aspect ratio without subsequent cropping/scaling.
You can only do audio multiplexing using the MPEG option(s) in Render>Output. You could do muxed playblasts in 2.49b but I haven’t yet tried it in 2.57, though I don’t know any reason why it wouldn’t work. However I don’t think the “native” Blender player can do muxed playback (couldn’t in 2.49b), so you’ll need to either go outside Blender or set up to use an external player in Blender (in Preferences, I think).
Can you elaborate on the issues with the playblast function in blender 2.57? I have been looking as I have been experiencing some problems, but I was unable to find similar posts. Currently, when I do an opengl render of the viewport, it takes FOREVER to render, almost as if it was rendering using the renderer, so it becomes basically unusable as you said. Where can I find more info?
I basically had to do a search of this forum, and didn’t save any of the thread links, sorry. The upshot was that quite a few people have been having probs with OpenGL rendering since 2.5x; many of the issues have been resolved, but some remain, in particular those of older graphics cards and those that can only do the output in increments of 256 or 512. In terms of your slow OpenGL rendering, are you using GLSL at the time? That may present some issues, though I haven’t read of anything specific in that regard.
I know from 2.49b that scene complexity can add to render time even for OpenGL, so that may have an influence in your case also, can’t say without knowing what your scene is like.
One thing that may also have an effect but not be immediately obvious is the use of certain modifiers on mesh objects. Mask, in particular, can slow things down, as can using high levels of Subsurf. Try disabling any modifiers and trying a render, see if it changes the render times.
An interesting update on this: My current “workhorse” comp with a legacy ATI card would not do OpenGL rendering at all despite another comp having no problems even though it has a lesser graphics chipset (An ATI MB arrangement). I had d/l’d the latest Catalyst for legacy cards when I first got the workhorse comp.
I recently went back to the AMD site and on a whim decided to d/l the same Catalyst version I’d been using (10.2) and re-installed everything over my initial drivers suite for the card. Lo and behold, all the OpenGL functions are now operating fine, including OpenGL render through the camera at the pixel dimensions specified in Blender. Apparently my earlier Catalyst install was messed up or somehow incomplete.
So I urge anyone using an older ATI card to make sure you have current drivers. I thought I did, since the Catalyst versions are the same, but that wasn’t the case.
It’s not perfect world, though – now I have some glitches in viewing texture images in the UV Editor window, the view of them sometimes gets “dynamically” smeared in very odd ways. Hope this doesn’t create probs with such features as GLSL and Texture Paint.
It’s definitely not a matter of scene complexity, as this happens even if I just animate the default cube. I’m not using GLSL or modifiers either, so that shouldn’t be the problem. I’ve even tried the same operation in two different machines and got the same result (super slow OpenGL render).
I also tried doing an OpenGL Render of the viewport using an output of 512 x 512, but it didn’t change anything.
It’s worth noting that if I do any of these tasks in Blender 2.49, everything works perfectly.
So, based on your answer, I think the most possible explanation is that the graphics card on my machines are not well supported (one is an integrated Intel, and the other one an ATI Radeon) on Blender 2.5X. Both of them have the latest drivers but are at least 3 years old.
Should I report this as a bug? I did a search on the 2.5 Bug Tracker and I didn’t find anything related.
The graphics card I recently “rejuvenated” with new drivers is more than 3 years old (a Radeon X700), and gives very fast OpenGL renders, so I’m doubtful that it’s the card causing a slowdown. Can you post one of your test .blends so I can see if it has the same result on my machine?
Sure, I’ve attached a sample scene with which you can test this issue. viewportRenderTest.blend (420 KB)
So you can get an idea, this scenes takes 1:40 min to do a normal render (default settings) and 40 seconds to do an OpenGL render, when in Blender 2.49 it just takes 2 seconds!!!
This was done with an Intel Core 2 Duo at 1.8 GHz, with Win 7, 4 GB of RAM and an integrated Intel Graphics Card, but it’s basically the same when I use my other laptop with similar specs and an ATI Raden 1400 card.
I ran your file twice using OpenGL animation. The first time through, Blender 2.57 r36147 (neither a nor b) got unresponsive for about a minute both before and after the rendering. The rendering itself took about 5 seconds for all 40 frames. On the second trial, Blender started rendering immediately and the render time was the same.
By comparison, fully-rendered sequence takes about 1.8sec per frame, or about 72 seconds total for the 40 test frames.
I also loaded up a much more complex file, one of my animated figures, and ran off about 110 frames in less than two minutes.
When you say 40 seconds to do the render in 2.57, is that a per-frame rate, or for all 40 frames of your test?
The 40 seconds are the total time for the OpenGL render of the 40 frames, or 1 second per frame. The full render of the same 40 frames, took 100 seconds (about 2.5 seconds per frame).
I’m using Blender 2.57b.
As you can see, the full render time is about the same, but the OpenGL render time is way slower on my machine. This definitely smells like a bug… something is not correctly supported on my system and the usual suspect is definitely my graphics card (Intel). The thing that gets me is that this happens on my other laptop as well, with a different card (ATI). Any ideas?
No ideas, really. but I can tell you that if the OpenGL animation works OK on a number of different machines with different hardware configs, both modern & “legacy,” it likely won’t be recognized as a bug. It’s just not feasible to address every possible hardware issue connected with OpenGL or any other code library for that matter.
However, I will give it a try tomorrow with 2.57b, see if anything has changed there.
Sorry I’m a bit tardy testing 2.57b. Running the same files as above (my generic-female staircase animation), using the low-rez proxy in the file I cranked out 170 frames in a little over a minute. Switching the view to the fully-modeled figure, the same frames took about 4 minutes in Multitextured mode. In GLSL mode, Textured Solid enabled, the frames took about 7 minutes. but that test also indicated a possible bug with GLSL/Textured Solid mode: The model’s assigned Material had no textures linked to it, just a basic shader. But in GLSL, the model did display a texture, an image I had applied to the model using UV mapping long before I did extensive editing on it. Seems the texture was linked to the UVSet in some fashion, so it displays in GLSL even though it is not part of the currently-assigned Material. I had to go into the UV Editor and manually Shift-Xbutton the texture to unlink it from the model.