[Bf-committers] Re: Orange branch schedule

Stealth Apprentice stealthapprentice at yahoo.com
Sat Jan 14 06:48:42 CET 2006


Another option is to allow plugins on render passes.
Then other renders can be plugged in as a pass - I'm
personally hoping to be able to inject hardware
accelerated render passes... Some passes OpenGL, some
passes software rendered, some passes image processing
etc.; preferably with a full compositing tree... :)

--- Rui Campos <rcampos at fusemail.com> wrote:

> 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
> future.
> 
> 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! :)
> > 
> 
> 
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at projects.blender.org
>
http://projects.blender.org/mailman/listinfo/bf-committers
> 


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 


More information about the Bf-committers mailing list