[Bf-compositor] a proposal for this list
blenderleo
blenderleo at gmx.de
Sat Nov 2 13:32:35 CET 2013
@Sebastian:
caching the nodes would probably also fix the undo issue.
Am 02.11.2013 13:20, schrieb Lukas Tönne:
> Sebastian: Could you create a few test files to demonstrate the
> sampling issues?
>
>
> On Sat, Nov 2, 2013 at 11:24 AM, Sebastian König
> <koenig.sebastian at gmx.net <mailto:koenig.sebastian at gmx.net>> wrote:
>
> Hey all!
>
> Great to see this list as place for discussions about the
> compositor! Let's form a Compositor Task-Force!
> From the talks with Jeroen and Monique at the Blender Conference I
> think we the users should first agree on what has to be fixed in
> the compositor and then give that list to the developers.
> So here is my list of things I would like to see fixed in the
> compositor. They are ordered by importance. Probably I forgot some
> things, but for the time being these are the things I would like
> to see fixed.
>
>
> *## Performance enhancement*
>
> 1. Be smarter about how to update nodes. Currently it feels as if
> the compositor would go over the entire node-tree and see what it
> has to do, even if all thumbnails and composite output are
> collapsed and there is only the viewer node connected to an image
> at the very start of the node tree.
>
> 2. Get rid of thumbnail previews, or at least make them collapsed
> by default.
> For me they have zero benefit, take up too much space in the
> composite layout, and suck performance. Just get rid of them!
>
> 3. Keep nodes in memory
> Related to the cache issue is that the compositor should be
> smarter when it comes to updates of node trees.
> It should detect what nodes have to be updated for the correct
> results and which nodes can be just kept in the buffer. I suppose
> this can be tricky memory-wise, but the current way of entirely
> re-calculating the whole node-tree just because of some change at
> the very end of it just sucks.
>
> 4. Lower resolutions for compositing.
> To check the overall result of the compositing you don't need to
> see the full resolution of composite. Having to render with
> different render dimensions however is a bit tedious. It would be
> nice to be able to set compositor to half or quarter resolutions
> to perform the composite. In the end you could then proceed to
> final resolution.
>
> 5. Cache Nodes
> For a lot of VFX compositing you cannot only composite for 1
> frame, you have to see it in motion. Rendering out final sequences
> is a bit tedious and not an ideal solution. Therefore it would be
> great to have some kind of cache for playback.
> Something that I imagine to be rather easy to do would be to have
> a cache node. You could drag it between any noodle, and that
> output would be cache for a give frame range. It could be cached
> either in RAM or on some kind of temp folder on hard drive. That
> way you can pre-render several cache sequences to both have a
> playback available, but also to stop one node tree from having to
> calculate all the time.
> One state of the node is "locked". It assumes to have a
> pre-rendered sequence in cache and won't calculate the node tree
> that leads into it.
> Second state of the node is "record". It will store any frame of
> the of the sequence in cache.
> Third state could be "passthrough" or so, in case the cache node
> should just be ignored.
> What i think would be nice about this method is that you can
> define some kind of milestones in your node tree.
>
>
>
>
> *
> *
> *## Functionality*
>
> 1. Make all nodes relative
> We have some nodes that allow a relative setting (blur size for
> example), while others only allow fixed pixel size (dilate erode).
> In practice that is really annoying because usually you start
> rendering and compositing at 50% and only for the final images you
> proceed to 100%. The compositor should have a unified setting for
> the size. Probably some thinking has to go into this, how to
> handle a pixel size setting, or if everything should be set in
> percentage, or, if you want to use pixels, if it should be
> relative pixels in relation to render dimensions.
>
> 2. Better sampling
> The current sampling sucks. For example the plane track node makes
> images incredibly blurry. I discussed that already with Jeroen at
> the Blender Conference, and apparently the entire sampling system
> has to be rewritten. But it would be worth it! :)
>
> 3. Masking
> Currently the Roto-workflow is still a bit clunky.
> Personally I would propose to merge clip-editor and uv/image
> editor. Because then we could do masking, tracking and painting of
> patches for compositing in 1 editor, which would be really nice.
> But I think this is a bigger issues, and maybe can be discussed
> separately.
>
> 4. Canvas
> The compositor is missing a better way to deal with different
> image dimensions. Arranging images and sequences freely on the
> canvas is important for compositing.
>
> 5. Overscan
> Related to the canvas topic is "overscan" (hope it's the right
> term), to allow rendering bigger than the final dimensions. That
> is needed for various things for example to be able to distort CG
> elements and composite them over footage with lens distortion.
>
>
>
> *## Wait, there's more!*
> Apart from the already mentioned issues there are other things
> that could be improved, but are maybe not doable soon.
>
> 1. New way of animating of nodes
> The way we animate nodes is a bit crappy at the moment. It's
> possible, but the way we can control the keyframes is not really
> nice. Maybe there could be some kind of NLA editor for compositing
> nodes, to easier drag around keyframe effects AND image sequences.
> See next topic.
>
> 2. Better way to deal with image sequences
> It is really annoying and tedious how we have to enter frame
> length and offset for movies and image sequences, if not
> everything starts at frame one. Could be controlled with some kind
> of composite NLA too? This could also touch the way to deal with
> length and start of image sequences and movie clips. But I suppose
> this is a bit complicated and maybe also not as super important.
>
>
>
> So, that's it.
> I'm sure I forgot some things, but so far this is what I would
> like to see improved.
>
> Cheers!
>
> Sebastian
>
>
>
>
>
> On 2. November 2013 at 10:54:04, David McSween
> (3pointedit at gmail.com <mailto://3pointedit@gmail.com>) wrote:
>
>> I also wondered if it would be useful for fx work to have access
>> to the open gl renders from 3d view? As a scene source just like
>> BI or Cycles. There are some sorts of comp effects that would
>> benefit from the speed of redraw, like distortion or mapping. To
>> do matte painting work etc.
>>
>> On 2 Nov 2013 17:10, "Aditia A. Pratama" <aditia.ap at gmail.com
>> <mailto:aditia.ap at gmail.com>> wrote:
>>
>> This is my proposal for blender compositor
>>
>> 1. viewer cache and viewer proxy for realtime playback, movie
>> clip editor has this function
>>
>> 2. new canvas for compositing where we can
>> translate/rotate/scale directly in the canvas...more
>> flexibility in the canvas.
>>
>> 3. ability to add comp to video sequence editor. We also can
>> have multiple composite in node editor...and calling them in
>> video seq editor for arranging and editing, it's like
>> improving post-processing workflow.
>>
>> On Nov 2, 2013 1:15 PM, "David McSween" <3pointedit at gmail.com
>> <mailto:3pointedit at gmail.com>> wrote:
>>
>> Hey Francesco, most recently I was troubled by the odd
>> image dimensions issue when trying to add or modify
>> non-project sized assets. That is my over height image
>> was cropped strangely when alpha overed. I gather from
>> the Holywood presentation at bcon13 it is a long standing
>> problem that isn't just a bug fix.
>> David
>>
>> On 2 Nov 2013 15:56, "Francesco Paglia"
>> <f.paglia.80 at gmail.com <mailto:f.paglia.80 at gmail.com>> wrote:
>>
>> Hi all!
>> It's a great news to have this list focused on the
>> compositor.
>> I don't really know which is the main intent of this
>> list so let me know if I'm wrong writing the next few
>> line.
>> What if we post here about real production case
>> demonstrating which are our actual limits so we can
>> discuss them with the module owner/s and figure out
>> how to address them?
>> There are many compositor in the community like
>> Bartek Skorupa, Sean Kennedy, Sebastian Konig, me and
>> many others that I don't know or heard about that I
>> imagine they can share their thoughts.
>>
>> Could be possible to know which dev is reading this
>> list since there are more areas of blender involved
>> since compositor is a made of nodes, animations,
>> compositing itself and render output?
>>
>> Hope to hear other subscribers opinion soon!
>> Ciao
>> Francesco
>>
>> --
>> Francesco Paglia
>> Vfx and Production Supervisor
>> e-mail f.paglia.80 at gmail.com
>> <mailto:f.paglia.80 at gmail.com>
>>
>>
>> _______________________________________________
>> Bf-compositor mailing list
>> Bf-compositor at blender.org
>> <mailto:Bf-compositor at blender.org>
>> http://lists.blender.org/mailman/listinfo/bf-compositor
>>
>>
>> _______________________________________________
>> Bf-compositor mailing list
>> Bf-compositor at blender.org <mailto:Bf-compositor at blender.org>
>> http://lists.blender.org/mailman/listinfo/bf-compositor
>>
>>
>> _______________________________________________
>> Bf-compositor mailing list
>> Bf-compositor at blender.org <mailto:Bf-compositor at blender.org>
>> http://lists.blender.org/mailman/listinfo/bf-compositor
>>
>> _______________________________________________
>> Bf-compositor mailing list
>> Bf-compositor at blender.org <mailto:Bf-compositor at blender.org>
>> http://lists.blender.org/mailman/listinfo/bf-compositor
>
> _______________________________________________
> Bf-compositor mailing list
> Bf-compositor at blender.org <mailto: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/20131102/75112c64/attachment-0001.htm
More information about the Bf-compositor
mailing list