[Bf-committers] Compositor migration

[Dalai Felinto]

Hi Jeroen,

>From a user perspective I would prefer this either (1) to be in a branch
(to be merged when complete) or (2) in trunk integrated seamlessly and
expanded while it goes (part of nodes in OpenCL and part in C, invisible
for the user).

The (2) would be ideal, but I'm not sure if it's even possible in terms of
implementation.

>From a developer perspective I would love to help with some simple nodes. I
never stopped to learn OpenCL so that would be a good chance to have a
grasp on it. Waiting for more information on how to help here.

Regards,
Dalai

2011/11/20 j.bakker at atmind.nl <j.bakker at atmind.nl>

> Hi all!
>
> We would like to discuss the migration strategic for the compositor.
>
> Actual state of the compositor is that the new engine is finished except
> for some OpenCL testing. The new kernel also needs a different way to
> implement nodes. This means that all nodes needs to be migrated to the new
> system. The code is available from a gitorious branch and documentation on
> architecture and 'technical' design is available.
>
> Here lies an opportunity to get familiar with the new system, or with
> compositing development in general. Many nodes already have a simple
> implementation but they need to be reviewed.
>
> In our opinion the best option is to migrate the new compositor engine next
> to the current engine in trunk, implement a switch between the two engines.
> The new engine will be marked 'experimental' and default not active.
> Second best option is to make the new compositor a technical target of
> Mango. This has not been discussed officially with Mango.
> The other two options (not our preferable) is to use a different branch and
> with the goal to perform the node migrations. After this is done it could
> be merged with trunk.
>
> Our preferred options are based on the (expected) activity in these
> branches. More people will be available to help out.
>
> We especially want to discuss what approach suits best and who wants to
> help out with the migration of the nodes.
> We need several people with different skills. Process of migrating a node:
> 1. select a node (list needed on wiki.blender.org)
> 2. design the solution by review similar nodes. The design will be the
> design of the node and its operations. (operations can be reused)
> 3. get approval of the design
> 4. Implement the node.
> 5. Test and document the changes in the node
>
> http://ocl.atmind.nl/doc/index.html documentation of the project.
> https://gitorious.org/blender-compositor/blender gitorious branch
>
> Regards,
> Jeroen & Monique
>  - At Mind -
>
>
> --------------------------------------------------------------------
> mail2web.com – Enhanced email for the mobile individual based on
> Microsoft®
> Exchange - http://link.mail2web.com/Personal/EnhancedEmail
>
>
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>