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

[joe]

We've discussed this before.  The algorithms for this are fairly
complex (zbrush nowadays sculpts in full 3d) as you have to stream the
mesh data to/from disk.  Partial redraw actually helps a lot on
sculpting, as does hiding stuff.  I think that's as good as it's going
to get for now.

Joe

2009/3/30 Mango Jambo <moraesjunior at gmail.com>:
> Hi, sorry the interruption, but I couldn't hang myself... :)
> How about to improve a way to get more speed in Sculpt Mode high
> resolutions? I Think that is one thing that really needs to be improved,
> IMHO. Some people told me Zbrush is a kind of 2.5D, and that is why it is
> faster then Blender sculpt, because it is like sculpting directly in the
> Normal map (since a resolution, may be, something like that) and not in the
> mesh. Sculpt Modifier? May be, I don't know. Unfortunately, I'm not a
> programmer! But would be great to have it working fast like Zbrush with high
> resolutions, right! With mask and specific local resolution on the model.
>
> Cheers
>
> Moraes Junior - aka mangojambo
> 3D Artist Animator
>
>
> 2009/3/30 joe <joeedh at gmail.com>
>>
>> Oh and sorry if I sound negative.  Most of the issues I'm taking have
>> to do with internal blender code issues.  I'm currently refactoring
>> the mesh code, and I'd like to avoid people touching certain parts of
>> that code without my input.
>>
>> If your proposal is approved, I'll have to coordinate with you on
>> parts of the implementation, so our two efforts don't conflict.  I
>> could even be your mentor, though perhaps Brecht would be better for
>> that.
>>
>> Joe
>>
>> On Mon, Mar 30, 2009 at 1:56 AM, joe <joeedh at gmail.com> wrote:
>> > 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
>> >>
>> >>
>> >
>> _______________________________________________
>> 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
>
>