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

[Jason Wilkins]

I am already designing gpuRetained, which will have an interface for
retaining and modifying a retained object.

There are not many places in Blender where this is "source compatible"
(meaning I can do search replace and things just work) but this is
definitely something I plan to do.

On Sat, May 26, 2012 at 8:48 PM, Sergej Reich
<sergej.reich at googlemail.com> wrote:
> 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