On Thu, Jun 27, 2013 at 1:44 AM, Sergey Sharybin <[email protected]>wrote:
> > From your reply, it sounds like the preview behavior is correct, and the > > render behavior is wrong. Aka, that Mix and Alpha Over nodes should > output > > in the resolution of their first input. Does that sound right? If so I'll > > file a simple bug/blend. > > Well, yes and no :) Just preview outputs in the actual resolution of a > buffer in compositor. Composite output crops stuff to a render resolution. > And this behaves as it is intended and used to behave since forever i > guess. > Can we agree that the preview appearance should always match the final appearance? This is not currently true. Technically speaking it's possible to make render result be the same as > composite, but that'd be a breakage of current things and here i could not > make any decisions. Would rather leave it to Ton to make such a decisions. I'm not sure what you mean by "make the render result match the composite". Let me rephrase the problem..... Currently there are many situations where composite "preview" and composite "final" do not look the same. This is because in final, nodes individually crop to "3d render resolution", but in preview they ignore render-resolution and "appear" to crop to the size of their first input. (see my blend file) As for how to fix this... Two options are: (a) Change the preview behavior to match today's "fixed resolution" final behavior..... Individual node previews will appear as if they are cropped to the current scene "render resolution", so they will appear the same as the "final". (b) Change the final behavior to match the "flexible resolution" preview behavior.... Individual node "final renders" will be done using strictly their input resolutions, ignoring render-resolution. "render resolution" will only affect the size of 3d RenderLayers sent into the composite, and (possibly) the final composite output size. Shot term, "a" might be a good option, because it will not change final render behavior, it'll just fix the preview to match. Long term, I think "b" is the right choice, for several reasons. 1. As far as I can see, B is strictly more capable than A. I believe everything users can do today in the compositor with "A" can be done with "B". I am certain there are several things that can be done with "B" that can *not* be done with "A". For example, today's "A" model can not handle composite situations where any intermediate nodes have outputs larger than the 3d render size. 2. Blender is an excellent 2d image and video compositor even if you don't need 3d rendering, arguably the best open-source compositor! I argue it is confusing for compositing only users to put in 2d sources, wire them together, and then have crop behavior affected by a 3d render-resolution settings for a 3d renderer the user is not even using. There are other UI issues here, like "Render Percentage" and the "Post Processing" section of the render panel, but I'll save that for a separate discussion. 3. A primarily composite user might want to add just a small amount of 3d to a video, such as a small rendered 3d titling + logo. For speed reasons it is beneficial to render only the small title, and translate it into place. This can't be done "interactively" today, because Well, [forcing all render-layers to the composite-scene-resolution] is how > render pipeline is designed to work atm, and it completely makes sense. I > could see how having different resolution could help in some cases, but in > general it'll be just asking for problems. Namely it'll be just PITA to > keep resolutions in sync in general > I think this could be easily accommodated by a (default set) option in the RenderLayer node to force the render in the current scene's resolution. VFX: for example you'll need to go over all the scenes o change render > percentage. > That's not something artists will expect to do. > Currently render-percentage and the compositor is very broken. It only "works" if you are only compositing 3d renders. If you add any video or image sources, the output is very very broken and requires manually adjusted scale nodes after every image/video source. Long term, I think "render percentage" should really be "proofing / proxy percentage" and should "magically" downsize all rendering, compositing, matting, video sequence editing, etc. I also think there is a growing UI issue regarding the view-specific Property-sidebars and the global Properties-panel. Because the Properties Panel is dedicated to 3d operations, the different view Property-sidebars (node-editor, movie-clip-editor) have started to effectively become "view specific" property panels. Which is sort-of okay, except that it's not possible for non-3d users (such as compositor or VSE only users) to use only a part of Blender without digging into the complexity of the global 3d Properties Panel. I'm going to make a proposal about this, but it's a separate discussion. _______________________________________________ Bf-committers mailing list [email protected] http://lists.blender.org/mailman/listinfo/bf-committers
