|
From: | vivek sagar |
Subject: | RE: GSoC 2013 |
Date: | Wed, 20 Mar 2013 14:27:24 +0530 |
Hi,
I have been following the instructions here: http://www.gnu.org/software/octave/doc/interpreter/Building-the-Development-Sources.html#Building-the-Development-Sources. I checked out the code and moved to the octave directory (step 1 & 2), but I cant seem to find the autogen.sh script. ls gives me the following: bootstrap configure.ac gnulib-hg Makefile.am scripts bootstrap.conf COPYING libgui NEWS src build doc libinterp oct-conf-post.in.h test build-aux etc liboctave README CITATION examples m4 run-octave.in Am I missing something ? Thanks Date: Tue, 19 Mar 2013 13:45:55 -0400 Subject: Re: GSoC 2013 From: address@hidden To: address@hidden CC: address@hidden On Tue, Mar 19, 2013 at 1:08 PM, vivek sagar <address@hidden> wrote:
Concerning the OpenGL selection mechanism, I just realize now that it was left in the project ideas. This is something that I handled in QtHandles, at least partially. See [1] and [2]. There's probably some improvement to be done, but it's already a good starting point.
Concerning the non-OpenGL renderer, the idea would be to re-engineer the opengl_renderer class and factor the common parts into a base class that is inherited by the actual renderers. Currently, there's loads of code in opengl_renderer that is related to axis transformation and is independent of the renderer. Once the code is reorganized, you can define a new renderer using another engine, like Cairo or Qt. The idea here would be to focus on 2D rendering, to produce high-quality graphics, where OpenGL is not really suited (like rendering overlapping surfaces lying at the same Z coordinate, from the camera point of view)
If you have some OpenGL knowledge, I can think of 2 possible improvement to the OpenGL renderer: - double-precision rendering: the current renderer delegates (almost) the entire transformation to OpenGL, but as OpenGL is using floating precision, it leads to incorrect plots when double precision is required (see for instance [3]); I would be in favor of addressing the issue in the renderer, by offsetting and scaling data in C++ before sending them to OpenGL
- transparency handling: the current OpenGL renderer does not support transparency; this is something I didn't port from JHandles, because I didn't really like the solution I used; the problem here is that, AFAIK, if you really want to have correct handling of transparency, you need to depth-sort the primitives before rendering them; there might be other solutions, I'm not really an OpenGL expert
Michael. |
[Prev in Thread] | Current Thread | [Next in Thread] |