[Bf-compositor] [Functionality] Make all node relative

[David Fenner]

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.
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.
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.

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...


2014-01-31 Lukas Tönne <lukas.toenne at gmail.com>

> From my point of view there are at least 2 separate (although related)
> issues:
>
> 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).
> 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.
>
> 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).
> 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).
>
> 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)
>
>
>
> On Wed, Jan 29, 2014 at 11:29 AM, Francesco Paglia <f.paglia.80 at gmail.com>wrote:
>
>> Hi all,
>> 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.
>> 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.
>> I imagine this sort of pipeline:
>> 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.
>> 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.
>>
>>
>>
>>
>> 2014-01-29 Greg Zaal <gregzzmail at gmail.com>
>>
>>> Hey folks :)
>>>
>>> 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).
>>>
>>> So an optional toggle (as with the blur node) would be good in my
>>> opinion, but it's not all that important either :)
>>>
>>> -Greg
>>>
>>> _______________________________________________
>>> Bf-compositor mailing list
>>> Bf-compositor at blender.org
>>> http://lists.blender.org/mailman/listinfo/bf-compositor
>>>
>>>
>>
>>
>> --
>> Francesco Paglia
>> Vfx and Production Supervisor
>>
>> mobile  +39 347.82.12.473
>> e-mail   f.paglia.80 at gmail.com
>>
>>
>> _______________________________________________
>> Bf-compositor mailing list
>> Bf-compositor at blender.org
>> http://lists.blender.org/mailman/listinfo/bf-compositor
>>
>>
>
> _______________________________________________
> Bf-compositor mailing list
> Bf-compositor at blender.org
> http://lists.blender.org/mailman/listinfo/bf-compositor
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/bf-compositor/attachments/20140131/9589767c/attachment-0001.htm