[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Ole Jacob Hagen
Subject: Re: Another thread on Oplot...and handle graphics.
Date: Wed, 20 Jul 2005 08:43:34 +0000
User-agent: Mozilla Thunderbird 1.0 (X11/20050307)

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. ;-)


Ole J.

Shai Ayal wrote:


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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]