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

[joe]

I'm not sure if this is a good plan. . .my idea was that editmode
would use VBOs (since it draws a ton more then object mode) and object
mode would either use VBOs too or just vertex arrays.  Streaming data
to the VBO in editmode would not be slow, so long as you only streamed
stuff that has changed.

Optimizing object mode is helpful, but it doesn't draw that much
compared to editmode, and imho not doing editmode negates much of the
benefits of using VBOs.  Since editmode draws more and slows down
before object mode does, it makes sense to not do it first.

Joe

2009/3/30 Aditya Vishwakarma <adi.vishwakarma at gmail.com>:
> 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
>
>