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

joe joeedh at gmail.com
Sun Mar 29 07:54:15 CEST 2009


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


More information about the Bf-committers mailing list