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

[David McSween]

I guess the scalability of some effects like glare could be overcome with
the use of drivers attached to render percentage.  But I find that drivers
often aren't called until frame change, making many driver solutions fail
(at least during testing period).

As for an active image area I can see the appeal of repurposing the
backdrop, as screen real estate can be a challenge with lots of nodes
spread across the compositor. Wouldn't it be more useful to enhance the uv
image editor window as the one stop shop for all 2d image editing?

In addition I would argue that the viewer node should have a multi slot
buffer like the render out window,  so we could display alternate node
outputs at reasonable resolutions.  As the thumbnails in each node are only
useful as signposts not comparative analysis.

Btw have a nice holiday.

Cheers
David
On 31 Jan 2014 08:13, "Jeroen Bakker" <j.bakker at atmind.nl> wrote:
>
> Hi all,
>
> We see that the users are discussing the technical solutions :). First of
all we should be very clear about what you want.
>
> The nodes that currently have the biggest (relative-resolution) issues
are the buffered operations (glare, filter). They assume that the current
pixel size is the actual pixel size, but that is not the case. Other
popular compositors work on a 'project' resolution, and let the user
downscale via a setting or dynamically too speed up the process. Biggest
difference is that Blender is an integrated product.
>
> From developer perspective we would better see other projects first like:
>  - make a decision on backdrop vs image viewer, usage of the viewer node,
render node, as this could really have big impact on everything we do,
especially when we know we want to have 'canvas-compositing' in the future.
this is a project you users could really help with discussing; and we can
help in structuring the discussion.
>
> So the question would be:
> 1. how does (from an artist point of view) the ideal compositor look like
that fits in Blender [artists in lead, developer as consult]. This is also
the reason why this list was set up.
> 2. using this as input we (the developers) can break-down it into
projects and make a logical order of these projects. [developer in lead,
artists as consult]
> 3. per project we can go into details [artists as in lead for the what,
developer on lead for the how]
>
> We are currently working on memory usage and performance, but have
nothing to show yet. See the above as an invitation to discuss the future
of the compositor. The next few weeks we won't be able to join the
discussion (holiday), but after that it would be nice if there are some big
topics we can discuss.
>
> Jeroen & Monique
>  - At Mind -
>
>
> On 01/29/2014 11:29 AM, Francesco Paglia 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/fc927ecb/attachment.htm