Hamish wrote: > > > I also added to the list nviz_cmd module. I am not > > > sure about its name. Any ideas? > > > > > > nviz.cmd > > > > I remember votes for d.3d and votes again this proposal. > > Any consensus before rc1? > > my 0c vote is for d.3d [for the d.* purists: could the outputted png be > used in the GUI display?].
That depends upon whether the module honours GRASS_PNGFILE, GRASS_RENDER_IMMEDIATE, GRASS_WIDTH, GRASS_HEIGHT, etc. E.g. if the GUI selects output to mmap()d BMP files or X Pixmaps, will the module honour that settting? If it doesn't, it isn't a display module. BTW, note that g.pnmcomp only works with PPM/PGM files, not PNG. > maybe m.out.3d? shrug > > the user is interested in what the module does, not which engine is used > in the background to do it. Sure. So long as the module honours all of the various environment variables (particularly those related to output format), it doesn't matter how it goes about it. But the chances are that anything which doesn't use the raster library won't honour those variables. Writing out a PNG file isn't much use if the GUI is expecting the output to be placed in PPM/PGM files or in an X Pixmap. In the worst case, you could write a d.* module which reads an image file then draws it using R_scaled_raster etc. For vector formats, that's going to produce sub-standard results compared to native rendering, but at least the output will end up where it's expected. -- Glynn Clements <[email protected]> _______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
