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

[Ton Roosendaal]

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