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

Aditya Vishwakarma adi.vishwakarma at gmail.com
Mon Mar 30 08:06:25 CEST 2009


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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/bf-committers/attachments/20090330/aa0eb8d7/attachment-0001.htm 


More information about the Bf-committers mailing list