[Bf-committers] GSOC : OpenGL Rendering Performance improvement in the view port

Aditya Vishwakarma adi.vishwakarma at gmail.com
Tue Mar 31 16:17:16 CEST 2009


Hi,
Thanks for the directions. I will definitely look at the codes from that
perspective

Aditya

On Tue, Mar 31, 2009 at 6:53 PM, Ton Roosendaal <ton at blender.org> wrote:

> Hi Aditya,
>
> I would advise to check a bit on our drawing code, especially how
> derivedmesh and modifiers are used. You can find most of this (2.48a
> trunk) in these files;
>
> source/blender/src/drawobject.c
> source/blender/src/drawmesh.c
>
> and
>
> source/blender/blenkernel/intern/DerivedMesh.c
> source/blender/blenkernel/intern/modifier.c
>
> There's quite a clear separation between meshes in "Edit mode" or
> regular meshes. However, there's also some overlap, especially in the
> case of modifiers.
>
> Ideally, the best performance improvements we would get if modifiers
> are well supported with VBOs, allowing shape-based transformations on
> the fly without overhead. Such transformations are very common for
> editmode too, and would therefore be interesting to support.
>
> To make it more complex even, we also have multi-res, and custom layer
> data in Blender (displacement, UV, colors), which is one of the bigger
> contributors to CPU overhead.
>
>
> -Ton-
>
> ------------------------------------------------------------------------
> Ton Roosendaal  Blender Foundation   ton at blender.org    www.blender.org
> Blender Institute BV  Entrepotdok 57A  1018AD Amsterdam The Netherlands
>
> On 30 Mar, 2009, at 8:06, Aditya Vishwakarma wrote:
>
> > Hi,
> >
> > thanks you all for the comments. I will modify my proposal to use
> > vertex arrays + indices initially.
> >
> > I was thinking that i would use VBOs only when blender in not in edit
> > mode. Constantly moving data to and from GPU would degrade performance
> > rapidly. Another problem with VBOs would be finding the upper limit of
> > number of vertices that can be stored on the GPU. Since this is a user
> > side issue, i would suggest that we make some sample scenes or design
> > tests that would find out the upper limit of memory needed.
> >
> > Besides having fair idea about drawing and fitting curves ( in our
> > Graphics course), i don't have any idea how meshes are drawn in
> > Blender.
> >
> > I have assumed that Blender rendering pipeline would be : [do all
> > work(which pixel to draw)] - [ apply transformations etc] - [draw
> > vertices]
> >  I also assumed that i would mostly be redesigning the 3rd stage, and
> > abstracting 2nd stage parts which have been mixed with the drawing
> > code.
> > Therefore, I frankly have no idea about how mesh is causing the problem
> >
> >  Thanking you
> > Aditya
> >
> >
> > On Sun, Mar 29, 2009 at 11:24 AM, joe <joeedh at gmail.com> wrote:
> >> On Sat, Mar 28, 2009 at 9:28 AM, Brecht Van Lommel
> >> <brecht at blender.org> wrote:
> >>  > There is a certain complexity associated with this project, but I
> >> think
> >>  > it is feasible and has well defined targets. I've reviewed the
> >> proposal
> >>  > in the google web app, and I agree display lists are not what this
> >>  > project should focus on first, but rather using vertex arrays and
> >> then
> >>  > vbo's or display lists as a second speedup.
> >>
> >> For VBOs, you'd have to have a system for incremental updates, which
> >>  is why I've stayed away from doing it myself (if you don't do that,
> >>  you might as well be using vertex arrays).  I guess it is possible,
> >>  maybe the same way ccgsubsurf does incremental updates; compare vert
> >>  positions with a stored mesh state in memory to see if an update is
> >>  needed, and rebuild the arrays on topological changes.
> >>
> >>  >
> >>  > Further, I don't know what this DerivedMesh refactor is. Purely
> >> from the
> >>  > view of functionality it is working now without major defects. The
> >> code
> >>  > could definitely be cleaner and easier to understand, but I don't
> >> think
> >>  > that should hold back anything, especially since I don't know of
> >> any
> >>  > concrete plans to actually do this refactor. To me it is just a
> >> part of
> >>  > the Blender code that can be iteratively improved.
> >>  >
> >>
> >> DerivedMesh can't handle ngons, so it's going to eventually need to be
> >>  modified for that.  We've discussed this heavily in the past, and
> >>  agreed that we do need to refactor it at some point.  Our short-term
> >>  plan for interfacing bmesh with DerivedMesh , is to tesselate ngons
> >>  into fgons (which  basically means hiding internal edges of the
> >>  tesselation), and modify key modifiers (just subsurf at the moment, I
> >>  think) to convert that back to ngons.   This approach tends to be
> >>  error-prone and slow, as we've seen with doing the same thing with
> >>  editmesh.
> >>
> >>  I don't think current DerivedMesh design has a future, so it'd be
> >> nice
> >>  if people didn't make things even more harder for when we do refactor
> >>  it (which I'll probably partly do myself, in small steps when bmesh
> >>  becomes stable).
> >>
> >>  Joe
> >> _______________________________________________
> >>  Bf-committers mailing list
> >> Bf-committers at blender.org
> >> http://lists.blender.org/mailman/listinfo/bf-committers
> > _______________________________________________
> > Bf-committers mailing list
> > Bf-committers at blender.org
> > http://lists.blender.org/mailman/listinfo/bf-committers
>
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/bf-committers/attachments/20090331/a2429f00/attachment.htm 


More information about the Bf-committers mailing list