[Bf-committers] Re: Orange branch schedule

Rui Campos rcampos at fusemail.com
Fri Jan 13 22:41:02 CET 2006

Hi Ton

This is probably too much to ask for, but since you are getting your
hands on it anyway, might as well keep this in mind.

Keep the Render infrastructure as much in a "Black Box" as possible,
allowing for a wrapper to be done to any other Render engine.
I say this because it would be really good to do "Shader" preview and
direct renders using another render engine right from inside Blender, it
would make Blender ahead of other packages.

The main point would be to leave this open, allowing for someone to just
build the integration of any other Render into Blender and use it as if
it was the Internal Render. Just a higher level API to the render that
would know which render to call and use this higher level API in any
render related thing inside Blender.

Also, making the Render as "close" as possible can also allow for a
"just render" deamon to be created and bundled for Renderfarms in the

Good luck on this, you have lots of work ahead of you.

-- Rui --

On Fri, 2006-01-13 at 17:15 +0100,
bf-committers-request at projects.blender.org wrote:

> Date: Fri, 13 Jan 2006 16:30:55 +0100
> From: Ton Roosendaal <ton at blender.org>
> Subject: [Bf-committers] Orange branch schedule
> To: bf-blender developers <bf-committers at projects.blender.org>
> Message-ID: <b35ac5720bc86d15e98b362fe9243c78 at blender.org>
> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
> Hi,
> I'm going to move now to the 2nd phase of the render coding project;  
> which is a full refactor of the source/blender/render/ module in  
> Blender.
> Targets are;
> - kill all bad level calls and abuse of render code in non-render  
> modules
> - means: build a good api to control the entire render process
> - separate the render process in a more controllable pipeline, I will  
> use ideas from the Reyes architecture for it
> - default render with "buckets" (tiles), and allow threads to do each a  
> full bucket (and more than 2 threads too)
> - prepare for smart bucketing of object/polygon data as well (later)
> - enable layer render (separate in front/back using blender layers or  
> scenes)
> - enable pass render (per layer, output RGB diffuse, RGB, Spec A, Z,  
> AO, etc)
> - generalize current passes for halos and transparent, so it can be  
> used for more (hair)
> - use exr to store all tiles and passes in a single file (but also  
> prepare for multiple computers to render tiles together)
> - enable motion blur by storing motion vectors in vertices, so blur  
> passes can be done in postproduction (or exported)
> - make a noodle editor for reading back the exr 'layer-passes' and  
> enable compositing
> - enable preview renders of any object/scene in any situation (like  
> within a border in 3d win)
> - enable preview renders that only re-render a specific material
> Hrms... the list is scary! :)

More information about the Bf-committers mailing list