octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: graphics and OpenGL rendering


From: Shai Ayal
Subject: Re: graphics and OpenGL rendering
Date: Wed, 26 Dec 2007 20:26:08 +0200

On Dec 26, 2007 11:43 AM, Michael Goffioul <address@hidden> wrote:
> On 12/26/07, Shai Ayal <address@hidden> wrote:
> > 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 wouldn't go that way (and I didn't in JHandles), because it duplicates
> some parts of the rendering code. Instead, I handled the layering
> aspects using OpenGL. Within the same axes, I use GL_LEQUAL
> as depth test, which gives correct results when you're in 2D mode.
> You can still see some artefacts when rotating in 3D mode (for
> instance for patch objects that are in the same Z plane, like
> contour group), but this can be reasonably handled by using polygon
> offseting. Overlapping axes is simply handled by resetting the depth
> bit before drawing an axes. Finally, I also disable the depth test when
> drawing text objects whose units is not data (because this is also
> how Matlab works).

I agree this is much cleaner solution

> > > 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.
>
> Attached (note that it's still experimental). The full rendering code
> exists in java form here:
> http://octave.svn.sourceforge.net/viewvc/octave/trunk/octave-forge/extra/jhandles/src/org/octave/graphics/GLRenderer.java?revision=4425&view=markup

Thanks. I'm looking at it.

> > 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.
>
> I think using C++ allows to produce more elegant/readable code.
> And if you can use a double dispatch mechanism, this avoids you
> to write something like this when iterating over children:
>
> if (type == "axes")
>   draw_axes ();
> else if (type == "line")
>   draw_line ();
>
> But you're right that the actual rendering core does not have to be
> C++. It's just easier, and you can make use of the liboctave classes
> to process data.

I did not explain myself clearly. I understand the advantages of using
c++ which gives you access to all of octave's data types, but What I
meant is that you don't really need to define objects for the drawing
itself. I agree that it makes the dispatch nicer but I think that's
just about it, and it does bring in some degree of copmlexity.

Shai


reply via email to

[Prev in Thread] Current Thread [Next in Thread]