Hi, <br><br>thanks you all for the comments. I will modify my proposal to use vertex arrays + indices initially. <br><br>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.<br>
<br>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. <br><br>I have assumed that Blender rendering pipeline would be : [do all work(which pixel to draw)] - [ apply transformations etc] - [draw vertices] <br>
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.<br>Therefore, I frankly have no idea about how mesh is causing the problem<br><br>
Thanking you<br>Aditya <br> <br><br><div class="gmail_quote">On Sun, Mar 29, 2009 at 11:24 AM, joe <span dir="ltr"><<a href="mailto:joeedh@gmail.com">joeedh@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">On Sat, Mar 28, 2009 at 9:28 AM, Brecht Van Lommel <<a href="mailto:brecht@blender.org">brecht@blender.org</a>> wrote:<br>
> There is a certain complexity associated with this project, but I think<br>
> it is feasible and has well defined targets. I've reviewed the 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 then<br>
> vbo's or display lists as a second speedup.<br>
<br>
</div>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>
<div class="im"><br>
><br>
> Further, I don't know what this DerivedMesh refactor is. Purely from the<br>
> view of functionality it is working now without major defects. The code<br>
> could definitely be cleaner and easier to understand, but I don't think<br>
> that should hold back anything, especially since I don't know of any<br>
> concrete plans to actually do this refactor. To me it is just a part of<br>
> the Blender code that can be iteratively improved.<br>
><br>
<br>
</div>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 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>
<font color="#888888"><br>
Joe<br>
</font><div><div></div><div class="h5">_______________________________________________<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>