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

[Mango Jambo]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/bf-committers/attachments/20090330/01a0bb5a/attachment.htm