[Soc-2012-dev] Viewport FX - Week 01

[Jason Wilkins]

The way I've implemented gpuImmediate is I have a Lock/Unlock pair
that enables and disables the buffers and Begin/End that marks the
boundaries of batches, and Vertex/Color/Normal/TexCoord which copy
components.

It is not faster than immediate mode for small batches.  Remember that
nVidia and ATI have had decades to make immediate mode fast
(considering what it is).  I'm not going to beat them using vertex
arrays for something they were not really designed for (small
batches).  That said, I am doing the best I can I think by adding the
Lock/Unlock pair.



On Sat, May 26, 2012 at 10:52 PM, Jorge Rodriguez <bs.vino at gmail.com> wrote:
> Hiya. Another SoC student here, I've some experience with porting immediate
> mode to vertex buffers and I wanted to chime in.
>
> In some of my projects I made an interface that works like immediate mode
> but instead of submitting verts to the gpu one at a time it would build a
> list of verts in a vector and send them all off at once. Is this what you
> intend to do? If so, it may help you to learn from my experience in the
> matter.
>
> Doing this has some advantages and some drawbacks. Obviously it reduces
> effort to port things to vertex buffers, and thus GL 3.0+. Mixing 2/3 is
> undefined hell and Blender should get away from that as fast as possible. It
> also has the advantage of being able to modify meshes on the fly. A vertex
> buffer doesn't need to be updated every frame and adding/removing verts or
> attributes is a breeze.
>
> The primary drawback is the copy and memory allocation cost of the vert
> vector. Depending on how you implement it, you may need to reallocate the
> vector every frame, that'll be slow. Then copying the verts one by one into
> the vector is also costly. It'll likely still be faster than immediate mode,
> but it could be optimized more.
>
> I found that for essential and large vert buffers you're best building a
> vertex buffer once and using it from there on, but for little things or
> things that update very often you can easily get away with an immediate mode
> stand-in.
>
> Hope that helps :)
>
>
> 2012/5/26 Sergej Reich <sergej.reich at googlemail.com>
>>
>> Hey Jason,
>>
>> since you're already working in this area I've got a feature
>> request/suggestion.
>> I wonder if it would be a good idea to introduce some sort of primitive
>> render API for the viewport.
>> There are a lot of places where you just want to draw simple wireframe
>> shapes like cubes, spheres, circles and what have you.
>> Instead of all systems having their own OpenGL code we could have
>> functions like add_line(float start[3], float end[3], float color[3],
>> int xray), add_box(float pos[3], float size[3], float color[3], int
>> xray), ... and so on.
>> These functions would not draw directly but just fill a buffer (or more
>> likely several buffers) which would be drawn at viewport refresh.
>>
>> I'm interested in this not only because it would allow us to get rid of
>> more GL code but because it would be very useful for debugging since you
>> could call those functions pretty much from anywhere.
>>
>> Of course this is just an idea, I haven't spent much time with blenders
>> drawing code yet so it might not be so simple.
>>
>> Regards, Sergej.
>>
>> Am Samstag, den 26.05.2012, 03:43 -0500 schrieb Jason Wilkins:
>> > Created the first part of an OpenGL compatibility layer: gpuImmediate
>> >
>> > gpuImmediate is meant to be a simple and direct replacement for
>> > glBegin/glEnd style programming.  The goal is to reduce the work
>> > required to port this style of code in cases where what is being drawn
>> > is so simple and small that the effort to convert it to a direct
>> > vertex array rendering style would be costly in developer time and
>> > regressions.
>> >
>> > glBegin/glEnd is inefficient for large amounts of geometry, but it has
>> > been highly tuned by the graphics card vendors to be about as good as
>> > it can possibly be.  I am not yet able to match the performance.  The
>> > only place I think this will matter however is in the text editor,
>> > which I was forced to rewrite some parts of, because it sent each
>> > character to the GL one. at. a. time.  Eventually I think it would be
>> > better to revisit the text editor by somebody interested in making it
>> > better generally, for now I just wanted to make sure I did not make it
>> > slower (it became unusable).
>> >
>> > Next week I hope to convert everything that uses GL immediate mode to
>> > use the new interface.  Also, I will be centralizing much of what
>> > would be considered GL utility functions in various parts of Blender
>> > into a central location to reduce duplication (for example there are 3
>> > different chunks of code that draw "unit cubes" and countless "draw a
>> > single line" routines.
>> >
>> > I'm keeping a day by day development diary here:
>> > http://wiki.blender.org/index.php/Viewport_FX_Design_Diary
>> > _______________________________________________
>> > Soc-2012-dev mailing list
>> > Soc-2012-dev at blender.org
>> > http://lists.blender.org/mailman/listinfo/soc-2012-dev
>>
>>
>> _______________________________________________
>> Soc-2012-dev mailing list
>> Soc-2012-dev at blender.org
>> http://lists.blender.org/mailman/listinfo/soc-2012-dev
>
>
>
>
> --
> Jorge "Vino" Rodriguez
>
> _______________________________________________
> Soc-2012-dev mailing list
> Soc-2012-dev at blender.org
> http://lists.blender.org/mailman/listinfo/soc-2012-dev
>