Re: graphics and OpenGL rendering

[Shai Ayal]

On Dec 26, 2007 12:06 AM, Michael Goffioul <address@hidden> wrote:
> On 12/24/07, Shai Ayal <address@hidden> wrote:
> > Michael, I think this is an excellent idea and fits in with my plans
> > perfectly. I have started writing the backend and decided that it
> > would be best to split the toolkit part (which in my case is based on
> > fltk) which deals with all the OS specific parts, and the generic
> > OS-independent OpenGL part which should be just that -- pure OpenGL.
> > It would be great to have help (and it sounds like it would be a lot
> > of help) in this part -- especially the 3D part which I do not have
> > any experience with (octplot is 2D).
>
> My rendering code does not make any difference between 2D and 3D:
> it's full 3D code, 2D is just a special case of 3D (view angles are
> [0 90]). I think it performs well and can render all Matlab core objects
> with a high compatibility. If you agree, it could be a starting point
> (once converted to C++).
How do you handle correct layering of objects in 2D? i.e. the correct
stacking of lines in a 2D plot? The only way I could think of doing it
in OpenGL, is by giving each object a different z coordinate to
enforce correct layering. This makes 2D "special" and not just a
special case of 3D. I hope you figured out something better.


> > I think we could probably end up
> > sharing everything but the font rendering for which you do using java
> > libraries and I plan to do using FTGL.
>
> Indeed, text rendering will still be toolkit dependent, because it's not
> handled by OpenGL directly. However, the idea is usually the same:
> render the text into a bitmap and transfer the bitmap to OpenGL.
> The main difference is then how the bitmap is generated.
> > Some questions remain to be answered:
> >
> > 1. How will we avoid code duplication -- i.e. we would need a single
> > cvs/svn repository. I planned on using octave's cvs. Will that work
> > for you?
>
> I don't have a developer access to it, so I would have to send you
> patches. But that's not a problem. The code I have for the moment
> is still experimental. I defined a graphics_renderer base class that
> defines the rendering interface and performs common tasks. The
> OpenGL rendering is implemented in a derived class that takes
> the octave graphics properties and render them using OpenGL
> (this leaves the possibility for other type of renderers). I can send
> you the code if you want.
Please send me the code.
When starting to write the rendering code myself, I realized that it
actually does not have to be c++ (except the code to access
properties). It could be done the "old-fashioned" way with a function
for drawing each type of object, the function taking as an argument
the properties class for the object, and perhaps some more auxiliary
arguments.

> The main problems I have for the
> moment are:
> - octave graphics objects are missing a lot of properties that are
> used by my rendering code; I think the best would be to take the
> matlab documentation and add all missing properties to the core
> objects
> - graphics properties are not typed, a lot are simply of type
> octave_value, without any distinction on the allowed values;
> I guess this will be changed in the near future, but I'd like to
> happen it soon as this has an impact on code that should use
> those properties

These two problems you mentioned are also at the top of my list (the
first one is even in the "official" goals for 3.1)

> > 2. After this is done, what will be the differences between the 2
> > backends? What will remain in Java in Jhandles? Will they just be two
> > similar OpenGL backends using different toolkits?
>
> Anything that is not OpenGL rendering will be different, but
> otherwise, they will be pretty similar (which is maybe a good thing...)

I think it IS a good thing

Shai