<div dir="ltr">Just an idea... As I saw you were talking about ways to translate/scale nodes in the compositor in a more intuitive manner, I have always thought that we could link the compositor with a 3d scene that is tweaked specifically for compositing. I know this sound crazy in the beggining, but just as nuke and other compositors include a 3d scene, why not use blender internal with minimal settings to compose? it renders quite fast with no extra stuff, it would be a little nuke. Basically what I am proposing is simply that a viewer node is parented to a default camera in the 3d view, and then the nodes that we choose (by toggling a 3d button) get "freed" from the viewer node and can be moved around in the 3d view, and then rendered back to the compositor. Of course these "freed" nodes could also be freed from being parented to the camera, so you could compose in a 3d space but with planes... you could also cast some shadows, do some distortion, apply modifiers, whatever you want... Of course, even if in the 3d view a node was closer to the camera than another one, I think that what should mandate is if the node is further down the node tree, instead of closer to the camera, but I'm not sure about this. <div>
Ok, I know that this sounds a little too much and not very precise, but in general terms it is simply using the 3d space for compositing, like nuke does. We have already a 3d space!! why make the compositor so limited? It could be a dream compositor, the possibilities are endless. </div>
<div>Think about it... as it is today if you want to put a matte painting you basically need to make a 3d render pass, scene or layer and render it out with the camera, but the process isn't interactive and you can't see the other layers on top and play with it, so it misses it's creative/experimental potential. It's also a pain if you want to animate this matte paintings, or foreground layers like smoke or whatever... having to render out isolated passes simply isn't intuitive or compositor friendly. </div>
<div><br></div><div>Ok sorry for the long text... just ideas, I just hope the 3d view get's used for the compositor, it's a logical step, and would be amazing for motion graphics and layered style animations... and easier to animate than what it is now...</div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">2014-01-31 Lukas Tönne <span dir="ltr"><<a href="mailto:lukas.toenne@gmail.com" target="_blank">lukas.toenne@gmail.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">From my point of view there are at least 2 separate (although related) issues:<div><br></div><div>1) Use relative sizes by default. This requires defining an abstract "canvas space" to which all nodes relate. The render output would usually span across the 0..1 width range and its aspect ratio defines the visible canvas (optionally render output could be set to "portrait mode" to use height instead).</div>
<div>In some cases you may actually want to use pixels (like the pseudo-aliasing mentioned by Greg), but even for blurring etc. a relative size is a better default to ensure the result is largely independent from final resolution.<br>
</div><div><br></div><div>2) Associate offset/size/rotation with things like image input nodes, to avoid having to always add translate/scale (usability feature). By default an image rect can be the full canvas width (this also ensures backward compatibility).</div>
<div>These transforms can be made accessible intuitively with boxes and handles in the compositor backdrop perhaps. We just have to be careful not to add too much noise in the node editor. With such widgets and drawing elements it would do two very different things, which may necessitate some kind of edit mode (nodes mode vs. compo canvas mode).<br>
</div><div><br></div><div>Internally the compositor could still use pixels on the lowest level (operations), but it should have a general mechanism to convert from canvas space into final pixel space reliably. Currently nodes like Translate still access the RenderData from context to convert relative values into pixels, we'd need a few functions to make this a common procedure and independent from render settings (see 1)</div>
<br></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Jan 29, 2014 at 11:29 AM, Francesco Paglia <span dir="ltr"><<a href="mailto:f.paglia.80@gmail.com" target="_blank">f.paglia.80@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi all,<div>As Sebastian pointed out in the wiki doc, the solution could be to have the size of the footage/renderlayer fixed to the final resolution and having the temp render files upsized to the proper value like the "proxy" solution other software adopt.</div>
<div>We do have another information that we should not forget the "percentage scale for render resolution" so maybe the behavior has to be careffully taken.</div><div>I imagine this sort of pipeline:</div><div>
doesn't matter which percentage of scale a render is done the renderlayer is always locked to the proper size set in the resolution panel and the test image is just blown up to that size.<br></div><div>a "proxy render" can be introduced in the compositing preference so we can easily switch between how many pixel consider to render per time (1/1, 1/2, 1/4, 1/8) and if the rendered picture match one of those resolution just consider it "as is" to not add other extra level of filtering.</div>
<div><br></div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">2014-01-29 Greg Zaal <span dir="ltr"><<a href="mailto:gregzzmail@gmail.com" target="_blank">gregzzmail@gmail.com</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><div dir="ltr">Hey folks :)<div><br></div><div>I agree, relative sizes would be very useful - however in some cases, absolute sizes are important (such as blurring a matte as a cheap form of anti-aliasing).</div>
<div><br></div>
<div>So an optional toggle (as with the blur node) would be good in my opinion, but it's not all that important either :)</div><span><font color="#888888"><div><br></div><div>-Greg</div></font></span></div>
<br></div></div><div>_______________________________________________<br>
Bf-compositor mailing list<br>
<a href="mailto:Bf-compositor@blender.org" target="_blank">Bf-compositor@blender.org</a><br>
<a href="http://lists.blender.org/mailman/listinfo/bf-compositor" target="_blank">http://lists.blender.org/mailman/listinfo/bf-compositor</a><br>
<br></div></blockquote></div><span><font color="#888888"><br><br clear="all"><div><br></div>-- <br>Francesco Paglia<div>Vfx and Production Supervisor</div><div><br></div><div>mobile <a href="tel:%2B39%20347.82.12.473" value="+393478212473" target="_blank">+39 347.82.12.473</a></div>
<div><div>e-mail <a href="mailto:f.paglia.80@gmail.com" target="_blank">f.paglia.80@gmail.com</a></div>
</div><div><br></div>
</font></span></div>
<br>_______________________________________________<br>
Bf-compositor mailing list<br>
<a href="mailto:Bf-compositor@blender.org" target="_blank">Bf-compositor@blender.org</a><br>
<a href="http://lists.blender.org/mailman/listinfo/bf-compositor" target="_blank">http://lists.blender.org/mailman/listinfo/bf-compositor</a><br>
<br></blockquote></div><br></div>
</div></div><br>_______________________________________________<br>
Bf-compositor mailing list<br>
<a href="mailto:Bf-compositor@blender.org">Bf-compositor@blender.org</a><br>
<a href="http://lists.blender.org/mailman/listinfo/bf-compositor" target="_blank">http://lists.blender.org/mailman/listinfo/bf-compositor</a><br>
<br></blockquote></div><br></div>