[Bf-committers] Thoughts on speeding up...

[Austin Benesh]

This is a very daunting task. The rendering engine is still the part
in Blender that gives me the most trouble, but I have a few ideas on
it. There could be a global class in addition to R (say, R2) that adds
up and stores the render faces, octree, etc. When a certain item in
the scene changes, those changes are reflected in R2. The entire scene
is not recalculated, just the part that is affected by the changes in
the scene. This could all be going on in an independent thread apart
from editing. I think Stefan is right in the fact that most people
don't have extreme machines, but I also think that Campbell is right
in the sense that those of us who are truely serious about Blender
will want it as optimal as possible.


-- Austin


On Thu, 24 Mar 2005 14:36:47 +0100, Ton Roosendaal <ton at blender.org> wrote:
> Hi,
> 
> Multithread, shared memory, coding is *extreme* work. I've managed to
> do so for the internal scanline render system, but after all
> initializing took place.
> Making the entire renderer a thread, with only using 'own' memory
> (which cannot be written or freed by Blender editor) is another huge
> task.
> 
> There are possibilities to bypass/hack it somewhat, my current notes on
> this look like this;
> 
> - Make internal global R struct allocated
> - create a setRender(char *name) call, returning new Render struct
>    plus make an associated getRender(char *name) and freeRender(Render
> *r)
> 
> then an API to talk to that:
> 
> - initRender(Render *r)
>    blocking function, creating all render faces, octree, shadowbuffers,
> etc
> - doRender(Render *r, int minx, int miny, int maxx, int maxy)
>    this can be the threaded call
> - endRender(Render *r)
>    freeing all render faces, octree, etc. Keeps Render itself
> 
> and an API to update partially stuff, like changing camera, tag 1
> material to be changed, 1 object geometry to be changed, etc. Have to
> study that part...
> 
> Result can be that any part in a 3d window (ortho too!) can just be
> 'border-ed' and rendered, while using material buttons, for example as
> preview.
> 
> -Ton-
> 
> 
> On 23 Mar, 2005, at 22:55, Austin Benesh wrote:
> 
> > Hi Ton,
> >
> >  
> >
> > I was looking through your thread render code and got some ideas to
> > help the speed of Blender. What could be done is two threads could be
> > created, one for interfacing and the other for rendering. Then, every
> > time allqueue(REDRAWVIEW3D) is called, the scene could be
> > "re-rendered" without actually drawing pixels and without sacrificing
> > speed. I'm working on an implementation of this right now. Please tell
> > me what's wrong with this idea, as I am sure there is something wrong.
> >
> >  
> >
> > -- Austin
> >
> >  
> > _______________________________________________
> > Bf-committers mailing list
> > Bf-committers at projects.blender.org
> > http://projects.blender.org/mailman/listinfo/bf-committers
> >
> ------------------------------------------------------------------------
> --
> Ton Roosendaal  Blender Foundation ton at blender.org
> http://www.blender.org
> 
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at projects.blender.org
> http://projects.blender.org/mailman/listinfo/bf-committers
>