WYSIWYG 3D Viewport Recording & Snapshots
As someone who spends more time modelling for physical creations than anything else, what I have always wanted as a feature is:
What You See Is What You Get: 3D Viewport POV Render/Record
Especially now with the new wonderful EEVEE real time 3D viewport rendering, I find myself craving the simplicity of quickly saving exactly what I see in my current 3D viewport view. This would be especially friendly to beginners (which I am not, been using for >6 years), as one of the learning curve bumps is that they have is they created something that looks cool in the 3D viewport, and then they have to stop and drag around a camera adjusting their viewpoint all over again to save it as an image.
Yes, I am very aware of the camera lock to view, but I don't do my modelling in locked camera view as it does not allow (among other things) hot key switch of ortho/perspective. And maybe I don't want to move my camera tripod around for a quick snapshot. Besides, the 3D viewport is itself a camera already, right? Why can't I render from it.
I currently do this a lot in a very hacky way by taking Windows screen captures. which I then have to crop and are still decorated with all the UI visual noise.
Imaging being out for a walk, and you see some nice view that you want to capture. As it works now, you have to stop, pull out SLR, put it on a tripod, chose and mount the right lens, aim, focus and zoom, rig lights, etc. That makes for fantastic composed pictures, which is why serious photographers do it (and which Blender does a fantastic job at) but sometimes you just want a quick snapshot like using your cellphone.
This could even be a video rendering option, again just like a cell phone video record (perhaps even with audio record? From mic or from what's playing on my computer? That's just a nice to have). Press Record and the screen is being recorded. Then as you drag things around in the viewport or change your view point, a video is recorded of exactly what you do when you do it, until you press Stop. Just like recording the entire UI screen using an external screen capture app, but now directly in Blender without the UI clutter (or optionally with special ones, perhaps using the applicable subset of the current "meta data/ burn into image" options, plus real-time running time code for videos). I can see this as a fantastic way to scratch together some quick storyboards without all of the work of key frame animating.
Of course these pictures/videos would be far inferior to what the final rendered animation/picture would look like, but as intermediate sketches like storyboards they would be amazingly useful.
With this proposed option (Perhaps Shift F11/F12 hotkeys, Camera Gizmo with Snap/Record/Stop/Play buttons?), I can orbit, fly, or walk around my model happily clicking away or recording a quick animation of exactly what is on my screen at that time. Ortho/perspective swaps are just a keypress, and literally what i see (minus all toolbars, gizmos etc) is what I get. Literally just what is in the 3D viewport exactly as seen on screen (Solid view / Wireframe, fine. Quick hide an object, fine it stays hidden, etc, etc, etc,).
With these options, what is Snapped/Recorded should be immediately saved to disk (perhaps a separate output location path in properties (Camera roll folder?), which if unset would cause a quick pop up asking for its location, with auto naming). Video (not frame images, actual video) would be stored in a preferences defined format. Resolution and camera shape is exactly the 3D viewport current shape and pixels on screen. No switch to image editor/new window, no second step to save the image, just point and shoot and it is stored. No running sequencer/compositor/etc. If Recording animation playback and the engine is dropping frames, fine. Record just what makes it on screen.
It should be even possible just grab the image already currently in memory (there must be a complete image that is being composited with all the on screen UI overlay elements before being drawn to screen somewhere in memory already). This should mean the amount of code to implement this should be pretty low, while the usability benefits and overall functional advances seem to be high.
18 Comments
In other softwares like Maya or 3DS, in the render settings you can choose which view is used for rendering. It can be a camera of course, but it can also be your actual viewport.
In Maya's render options:
As you can see, we can select to choos the camera1's view, as well as the current perpective viewport, etc.
Some cool things with that workflow :
However, the issue with "viewport POV" rendering, is that the resulting rendered area and resolution doesn't correspond to what you see. It a problem we already have when we do an OpenGL render in blender.
The solution in other softwares is to enable the "safe frame"or "film gate" :
That option enables the safe frame on top of the current viewport according to the output render resolution ratio. What you see inside the safe frame is what you get in viewport render.
* @-L0Lock- * Thanks for including the details regarding Maya, cool info. The idea of having the "safe frame" is a interesting add to this suggestion. Effectively Blender could just pick up the render shape ratio and put the box on screen for the viewport camera exactly like any other camera, filling the viewport as much as possible, so this should be only a pair of horizontal or vertical lines, never cropping in both dimensions...
I find this to be fine as long as it is a toggle only, effectively making the viewport's internal camera effectively an always locked to view camera that fills as much of the screen as possible. Many times however, I would argue that the output shape should just be exactly what is on screen, just without the UI overlay decorations. I envisioned this as output image is just exactly whatever the shape and pixel count of the viewport, which is why I titled the comment as WYSIWYG.
I do understand that external tools to much of this, such as the snipping tool you used to capture the GIF loop (nice character by the way). I just believe this to be such a low hanging fruit that would improve the workflow for many users from beginners to advanced that it would be nice to be baked in.
What we are both describing is a tool to effectively mimics a DP and Director scouting a location for the next scenes shots, sometimes snapping pictures or grabbing a quick video. Much of the time, they will just shoot the picture with whatever camera is convenient, e.g. cell phone, fully aware that the shape of the saved image has nothing to do with the aspect ratio and field of view of the lens in use. Other times they will view the location through a "Directors Viewfinder" (of course now there is phone apps for this) to see the safe areas and perspective compression effect of the expected lens. There is always validity in considering established techniques in use in related fields.
The other thing we are describing is almost identical to the model making department, shooting photos of work in progress. In those cases they would have no reason to care about safe areas or the fact tools are on the workbench, they just want to get images of the models for reference or to share with collaborators (that would be with Safe mode off).
Are you referring to Open GL Render ?
* @ammusionist * Actually I am referring to rendering and saving to disk the current point of view in the 3G viewport as positioned, without going to the extra step of placing a new camera. F12 using viewport "camera" rather than placed camera.
Basically screenshot without all the clutter and integrated in to the app vs external OS tool.
For recording, it would be exactly like screen recording with external app, again without the visual clutter.
* @ian.finnimore * So this could be fulfilled if OpenGL Render were to use the current point of view instead of the scene camera view?
* @ammusionist * Actually, I wouldn't consider the particular render engine as even correlated with this suggestion
I agree the OpenGL mode as very useful closer towards the end of the process, where I want a quicker render time (rather than running a 30 minute per frame render for example) with some sacrifices, but has nothing to do with my suggestion.
Don't think "Render" as much as screen shot / screen record. What is in the viewport right now, as is, the pixels already on the on screen (discarding UI overlay elements) is what I am suggesting to save. Functional even in edit mode, with part of the mesh hidden, and some edges selected. Just exactly what is on the screen already.
Same goes for recording. Say I am setting up a part of a shot, and want to hit record, pick a character up and bounce them around the screen, then hit stop and the video is saved. I can send that scratch video to a collaborator (or as self notes for storyboards) with the text (or even better mic audio or currently playing audio) "so in this shot the critter goes here, and here, and then falls here... " Like that.
Snapshots, not renders, and not extra steps to save image, useful for "scouting" possible camera angles, or even "hey, you have to clean up this part of the mesh that is highlighted...." images.
Also great for people who are just using blender for 3D printing modelling (a part of our community), as If I am "rendering" in plastic, why do I need to use use a light rig?
Great for "newbies", who can create quick "look mom, see what I made, stick it on the fridge" grade images, while they figure out a lighting rig and camera placement.
* @ian.finnimore * But what * @ammusionist * is saying is that this feature already exists . We call it the OpenGL render (though I prefer the other term many have adopted: Boomsmash). Blender already has what you're looking for.
the only thing missing is being able to do a final render out of the viewport view instead of being constrained to a camera. and recording your actions (though there was a screen recording tool in previous versions right ?)
* @-L0Lock- * We've always been able to do an OpenGL/Viewport render from any arbitrary view other than the camera if we'd like. The realtime recording is tougher to pull off in 2.80 (yes, we did have it in 2.79). The current fallback would be to "live animate" by using autokey and moving the object around while you're in playback. Then, once the animation is capture, you can go back and Viewport Render that.
but we can't do cycles/eevee renders outside a camera.
* @-L0Lock- * I just tested using Eevee in Rendered view in the Viewport. Viewport rendering works just fine outside of the camera. It won't for Cycles, but Eevee isn't a problem at all.
* @Jason van Gumster * oh ok then, just needs cycles support x)
* @-L0Lock- * @Jason van Gumster, OK, now I see what you're getting at. [For those playing along Viewport Render is under menu View in 3D view (or F3 search). Searching for OpenGL doesn't get any hits).
I had seen that, but at the time I was in a cycles rendered view, and all that was apparent was a switch to the image editor, not the render.
I see it is running through the render pipeline again, even though the desired output is already in the video buffer (which would automatically solve the Cycles Rendered View problem), and personally I would not use the render output frame size (at least optionally) but would just grab the shape of the viewport as things get cropped that were visible in the viewport, but OK.
It might be good to move the action to the Render menu as it is a little obscure living under view, but hey one of the things we all love about Blender is trying to discover where certain commands/hotkeys live. This one is going into the quick favorites.
OK, I am sorry for the blob of text. When I typed it, it had paragraph breaks. This site then timed out my session cookie, and I had to save and cut/paste into a new comment, which seems to have stripped all the line breaks. I will edit and see if I can fix it...
* @ian.finnimore * Nope, site rendering is seemingly stripped of paragraph breaks even though they show in editing, nothing I can do. so the TL/DR version is: Ability to be able to snapshot and video record with instant save to disk exactly what is shown in the 3D viewport.
* @ian.finnimore * Looks like a bug in how it's parsing Markdown. I'll go ahead and report it.
* @Jason van Gumster * Thanks Jason. Didn't want this suggestion to be dismissed out of hand simply because it looks like a crazy manifesto rant :)
* @Jason van Gumster * Looks fixed now. Thanks for the quick turnaround!