[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