Hi Jeroen, I'm not keen on this proposal - it seems to mix two concepts and does it in a bit of an odd way.
First concept is region of interest, or bounding box: It should be possible to define regions of interest within which only the contained pixels will be processed/output/etc. This can be used for things like the oldskool preview window in blender's compositor to only update a cropped subset of the pixels to speed things up while tweaking, but can also include things like having different data windows and display windows (like EXRs contain). Sometimes you'll want to render an EXR with overscan, so the data window is larger than the display window, which lets you do things like add distortion, camera shake, etc using the extra pixels around the edge of the visible frame so there aren't edge artifacts. The second concept is a matter of transforming nodes: IMO this should really be implemented as a 3D transformation matrix per node (better to use 3D to be future proof, even if only 2D is used atm). I'm pretty sure most other good compositors do it this way as well. All transform nodes should just be modifying that matrix, passing on a reference to the original buffer, and not doing any processing of their own. Rather, whenever real pixels are needed (for example, a blur) in the function that retrieves the buffer (or tile) for the blur node, it should then sample the original buffer once, using the current transform matrix. This allows concatenation of transforms (as in Shake and Nuke), where you can have as many different transform nodes one after the other like rotate->shear->scale->translate->rotate, and it will only sample the image once, to prevent deterioration in image quality. There's a bit of info on these things here and in the nuke docs: http://www.nukepedia.com/written-tutorials/10-tips-to-optimising-nuke-and-creating-efficient-workflows/ Matt On Wed, Aug 3, 2011 at 1:27 AM, [email protected] <[email protected]>wrote: > Hi all, > > Some of you might already know this, but I have done some effort in making > canvas compositing working in Blender. > > I have made a draft-proposal to see where it should go to. I would like to > have feedback on the user interface level. How can we make this usable to > our users? How can we keep the render width/height settings in sync with > the canvas width/height? > > In the current compositor the composite works on a by code defined > coordinate system. This coordinate system (ImBuf x, y) cannot be changed or > even used by the user. This proposal will open up this coordinate system > and implement canvas compositing in Blender. This is possible as the > compositor redesign project does not enforce a coordinate system and > handles data/memory in a different way (no buffers). > > This will introduce 4 new concepts in the compositor > > - Ordered List Item Canvas (being the existing background grid) > - Viewport (the camera that the compositor looks through, the area that > will be the result of the composite) > - Positionable input nodes (data can be positioned/scaled/rotated on the > canvas) > - Backdrop handles (interactive handles on the backdrop) > > > The link below has to proposal including sample images and a (technical) > video. > > http://ocl.atmind.nl/doku.php?id=design:proposal:compositor_canvas > > Happy Blending! > Jeroen > > -------------------------------------------------------------------- > mail2web.com – Enhanced email for the mobile individual based on > Microsoft® > Exchange - http://link.mail2web.com/Personal/EnhancedEmail > > > _______________________________________________ > Bf-committers mailing list > [email protected] > http://lists.blender.org/mailman/listinfo/bf-committers > _______________________________________________ Bf-committers mailing list [email protected] http://lists.blender.org/mailman/listinfo/bf-committers
