Hi, <div><br></div><div>Thanks for the directions. I will definitely look at the codes from that perspective</div><div><br></div><div>Aditya<br><br><div class="gmail_quote">On Tue, Mar 31, 2009 at 6:53 PM, Ton Roosendaal <span dir="ltr"><<a href="mailto:ton@blender.org">ton@blender.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Hi Aditya,<br>
<br>
I would advise to check a bit on our drawing code, especially how<br>
derivedmesh and modifiers are used. You can find most of this (2.48a<br>
trunk) in these files;<br>
<br>
source/blender/src/drawobject.c<br>
source/blender/src/drawmesh.c<br>
<br>
and<br>
<br>
source/blender/blenkernel/intern/DerivedMesh.c<br>
source/blender/blenkernel/intern/modifier.c<br>
<br>
There's quite a clear separation between meshes in "Edit mode" or<br>
regular meshes. However, there's also some overlap, especially in the<br>
case of modifiers.<br>
<br>
Ideally, the best performance improvements we would get if modifiers<br>
are well supported with VBOs, allowing shape-based transformations on<br>
the fly without overhead. Such transformations are very common for<br>
editmode too, and would therefore be interesting to support.<br>
<br>
To make it more complex even, we also have multi-res, and custom layer<br>
data in Blender (displacement, UV, colors), which is one of the bigger<br>
contributors to CPU overhead.<br>
<br>
<br>
-Ton-<br>
<br>
------------------------------------------------------------------------<br>
<font color="#888888">Ton Roosendaal Blender Foundation <a href="mailto:ton@blender.org">ton@blender.org</a> <a href="http://www.blender.org" target="_blank">www.blender.org</a><br>
Blender Institute BV Entrepotdok 57A 1018AD Amsterdam The Netherlands<br>
</font><div class="im"><br>
On 30 Mar, 2009, at 8:06, Aditya Vishwakarma wrote:<br>
<br>
> Hi,<br>
><br>
> thanks you all for the comments. I will modify my proposal to use<br>
> vertex arrays + indices initially.<br>
><br>
> I was thinking that i would use VBOs only when blender in not in edit<br>
> mode. Constantly moving data to and from GPU would degrade performance<br>
> rapidly. Another problem with VBOs would be finding the upper limit of<br>
> number of vertices that can be stored on the GPU. Since this is a user<br>
> side issue, i would suggest that we make some sample scenes or design<br>
> tests that would find out the upper limit of memory needed.<br>
><br>
> Besides having fair idea about drawing and fitting curves ( in our<br>
> Graphics course), i don't have any idea how meshes are drawn in<br>
> Blender.<br>
><br>
> I have assumed that Blender rendering pipeline would be : [do all<br>
> work(which pixel to draw)] - [ apply transformations etc] - [draw<br>
> vertices]<br>
> I also assumed that i would mostly be redesigning the 3rd stage, and<br>
> abstracting 2nd stage parts which have been mixed with the drawing<br>
> code.<br>
> Therefore, I frankly have no idea about how mesh is causing the problem<br>
><br>
> Thanking you<br>
> Aditya <br>
> <br>
><br>
> On Sun, Mar 29, 2009 at 11:24 AM, joe <<a href="mailto:joeedh@gmail.com">joeedh@gmail.com</a>> wrote:<br>
</div><div><div></div><div class="h5">>> On Sat, Mar 28, 2009 at 9:28 AM, Brecht Van Lommel<br>
>> <<a href="mailto:brecht@blender.org">brecht@blender.org</a>> wrote:<br>
>> > There is a certain complexity associated with this project, but I<br>
>> think<br>
>> > it is feasible and has well defined targets. I've reviewed the<br>
>> proposal<br>
>> > in the google web app, and I agree display lists are not what this<br>
>> > project should focus on first, but rather using vertex arrays and<br>
>> then<br>
>> > vbo's or display lists as a second speedup.<br>
>><br>
>> For VBOs, you'd have to have a system for incremental updates, which<br>
>> is why I've stayed away from doing it myself (if you don't do that,<br>
>> you might as well be using vertex arrays). I guess it is possible,<br>
>> maybe the same way ccgsubsurf does incremental updates; compare vert<br>
>> positions with a stored mesh state in memory to see if an update is<br>
>> needed, and rebuild the arrays on topological changes.<br>
>><br>
>> ><br>
>> > Further, I don't know what this DerivedMesh refactor is. Purely<br>
>> from the<br>
>> > view of functionality it is working now without major defects. The<br>
>> code<br>
>> > could definitely be cleaner and easier to understand, but I don't<br>
>> think<br>
>> > that should hold back anything, especially since I don't know of<br>
>> any<br>
>> > concrete plans to actually do this refactor. To me it is just a<br>
>> part of<br>
>> > the Blender code that can be iteratively improved.<br>
>> ><br>
>><br>
>> DerivedMesh can't handle ngons, so it's going to eventually need to be<br>
>> modified for that. We've discussed this heavily in the past, and<br>
>> agreed that we do need to refactor it at some point. Our short-term<br>
>> plan for interfacing bmesh with DerivedMesh , is to tesselate ngons<br>
>> into fgons (which basically means hiding internal edges of the<br>
>> tesselation), and modify key modifiers (just subsurf at the moment, I<br>
>> think) to convert that back to ngons. This approach tends to be<br>
>> error-prone and slow, as we've seen with doing the same thing with<br>
>> editmesh.<br>
>><br>
>> I don't think current DerivedMesh design has a future, so it'd be<br>
>> nice<br>
>> if people didn't make things even more harder for when we do refactor<br>
>> it (which I'll probably partly do myself, in small steps when bmesh<br>
>> becomes stable).<br>
>><br>
>> Joe<br>
>> _______________________________________________<br>
>> Bf-committers mailing list<br>
>> <a href="mailto:Bf-committers@blender.org">Bf-committers@blender.org</a><br>
>> <a href="http://lists.blender.org/mailman/listinfo/bf-committers" target="_blank">http://lists.blender.org/mailman/listinfo/bf-committers</a><br>
> _______________________________________________<br>
> Bf-committers mailing list<br>
> <a href="mailto:Bf-committers@blender.org">Bf-committers@blender.org</a><br>
> <a href="http://lists.blender.org/mailman/listinfo/bf-committers" target="_blank">http://lists.blender.org/mailman/listinfo/bf-committers</a><br>
<br>
_______________________________________________<br>
Bf-committers mailing list<br>
<a href="mailto:Bf-committers@blender.org">Bf-committers@blender.org</a><br>
<a href="http://lists.blender.org/mailman/listinfo/bf-committers" target="_blank">http://lists.blender.org/mailman/listinfo/bf-committers</a><br>
</div></div></blockquote></div><br></div>