Re: Another thread on Oplot...and handle graphics.

[Ole Jacob Hagen]

Since Oplot is using Coin3D as visualisation library, Oplot can use two 
methods to generate postscript files.

Method 1:

OffscreenRenderer generates texture maps of on the fly  as bitmaps or 
postscript.

Offscreen rendering is internally done through either a GLX offscreen 
context (i.e. OpenGL on X11) or a WGL (i.e. OpenGL on Win32) or AGL 
(i.e. OpenGL on the Mac OS) ditto. If the OpenGL driver supports the 
pbuffer extension, it is detected and used to provide 
hardware-accelerated offscreen rendering.

One particular usage of the SoOffscreenRenderer is to make it render 
frames to be used for the construction of movies. The general technique 
for doing this is to iterate over the following actions:

   * move camera to correct position for frame
   * update the |realTime| global field (see explanation below)
   * invoke the SoOffscreenRenderer
   * dump rendered scene to file

..then you use some external tool or library to construct the movie 
file, for instance in MPEG format, from the set of files dumped to disk 
from the iterative process above.

Method 2:

SoVectorizeAction is the base class for vectorization of Coin scene graphs.

Currently supported geometry:

   * Triangles (polygons will be tessellated)
   * Line segments
   * Points (can be drawn as circles or squares)
   * 2D text
   * 3D text
   * Images

Texturemaps are not supported.

SoOffscreenRenderer and SoHardCopy is included in the Coin3D library.

Oplot is using SoOffscreenRenderer as default today, but a dialog-based 
printing dialog where a user can choose what method to choose from is 
under development. ;-)

Cheers,

Ole J.




Shai Ayal wrote:

> Ole,
>
> One of the most importand features, IMHO, is hardcopy. Do you support
> "prinitng" to some vector file format (e.g. ps/pdf/fig) ? If not this
> should certainly be on your high priority list. Note: It is important
> that you support some vector format which is resolution independant so
> that real hardcopy on a printer/published paper will look acceptable.
> Bitmap formats are nice (and might be easier to implement) but are
> good for screen display at most.
>
> Shai
>
>