[GRASS-dev] [SoC Report] 2.5/3D visualization tool for wxPython GRASS GUI

[Glynn Clements]

Martin Landa wrote:

> 1. What did you get done this week?
> 
> I worked on experimental NVIZ CLI module, I added some new options and
> fixed various bugs.
> 
> http://trac.osgeo.org/grass/browser/grass-addons/visualization/nviz2/cmd
> 
> 2. What do you plan on doing next week?
> 
> The next week I would like to finish very limited version of NVIZ CLI
> module. Afterwards I will start working on wxGUI NVIZ tool based on
> NVIZ CLI functionality (planned 'nvizlib' used by wxGUI tool and CLI
> module).

BTW, are you planning on cleaning up the OGSF library at all?

One of its main structural problems is that it has a fair amount of
"private" state (e.g. lighting), and the management of that state
(including synchronisation with OpenGL's state) is, to put it mildly,
rather "ad hoc".

This can be a significant problem in two areas:

1. If you want to deal with multiple views, there is only one set of
state variables, so you would need to explicitly re-initialise
everything when switching between views.

2. If you want to replicate a view onto a different GLX (etc) context,
there's no convenient way to do so.

IOW, for anything other than a single view and a single context, the
application must keep its own copy of the state, in addition to the
copies held by OGSF and OpenGL itself.

One option is to just rip out all of OGSF's internal state, so the
code would render with the current OpenGL settings. Applications would
either call OpenGL functions directly, or call OGSF wrappers which
pass the data directly to OpenGL *without* keeping a private copy
around.

Another option would be to formalise the state management, ensuring
that every "set" function has a corresponding "get" function, and with
clear mechanisms for switching between different contexts, and pushing
the internal state out to OpenGL.

-- 
Glynn Clements <glynn at gclements.plus.com>