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 <[EMAIL PROTECTED]> _______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
