A new version of the Linux framebuffer patch to povray-3.6.1 for Unix
is available for download here:

http://pov4grasp.free.fr/download/povray-3.6.1-fb-0.2.tar.gz

	This version 0.2 aims at supporting all color depths (bpp) and fix
some of the problems found in version 0.1 released almost a year ago; see:

http://news.povray.org/povray.unix/thread/%3C4132ac2b%40news.povray.org%3E/


	The list below summarizes the changes from version 0.1 to version 0.2:

- the fbdev.* source files are renamed to the more generic fb.* in order to
   avoid confusion with the fbdev driver from XFree86.  Please remove the old
   fbdev.* files before applying this patch.

- add proper support for 8, 15, 16, 24, and possibly 32 bpp color depths
   and at any screen resolution (tested at 640x480 and 1024x768 using the
   vesafb driver).  32bpp color depth was not tested but is believed to
   work as well as the 24bpp mode.  Please report any problem otherwise.

- the 8bpp mode (256 colors) has two different color palettes implemented:
   a generic 216 color palette (aka "web" palette made of 6x6x6 colors) and
   a slightly better 240 color palette (5x8x6 colors) which should somewhat
   limit dithering artefacts.  The 240-color palette is the default; the "web"
   palette can be selected at compile-time only, by setting the USE_COLORMAP
   definition at the top of unix/fb.cpp.  A 240-gray-level palette is also
   available when one specifies e.g. "Palette=G" in the povray.ini file.
   Note that 240 custom colors are the maximum available, since the remaining
   16 colors are kept unchanged to avoid ugly color flickering effects at the
   console (these are the default system colors).

- the 15, 16, 24 (and 32) bpp modes do not use a color palette and give
   very similar visual results.  In version 0.1 only the 16 bpp mode would
   work correctly.

- the patch now honors the FRAMEBUFFER environment variable, or uses /dev/fb0
   as the default framebuffer device otherwise.  There's also no more possible
   interference with the svga display.  There is _still_ possible interference
   with a X Window session running on top of the framebuffer console (see
   the old threads linked above for more detail on this topic).

- the console state with respect to keyboard input is now properly restored
   whenever the render is stopped.

- version 0.1 had a "hidden" (undocumented) feature which allowed to dump
   the screen to a PPM file.  Press the 'q' key at any time during the
   rendering stage to output a dump.ppm file in the current directory.  Note
   that this feature does currently bypass the IO-restriction scheme and is
   therefore "dangerous" - use at your own risk.  It will be slightly reworked
   in the future.


	To apply the patch, untar the archive and copy all the files from
the newly created povray-3.6.1-fb-02/ directory to the corresponding locations
in the source distribution of povray-3.6.1.  Then run the ./configure script
as usual, and 'make check' to build and run a test render.  The tarball provides
only the new and modified files, as compared to the official povray-3.6.1 for
Unix source archive.

	See p.binaries.images for examples at all supported color depths.
The images were obtained using the dump screen feature mentioned above.

	- NC

Post a reply to this message

Nicolas Calimet wrote:
>     A new version of the Linux framebuffer patch to povray-3.6.1 for Unix
> is available for download here:
> 
> http://pov4grasp.free.fr/download/povray-3.6.1-fb-0.2.tar.gz
> 

Neat - seems to work fine.

Are you sure the vga environment variable is the right way (tm) to 
detect a framebuffer display?

> - add proper support for 8, 15, 16, 24, and possibly 32 bpp color depths
>   and at any screen resolution (tested at 640x480 and 1024x768 using the
>   vesafb driver).  32bpp color depth was not tested but is believed to
>   work as well as the 24bpp mode.  Please report any problem otherwise.

Works fine at both 1600x1200@16 and 1400x1050@24.  Note for higher 
resoluation modes it could be nice to have the option not to center the 
render view but put it in the upper right corner (so you can see text 
messages when doing renders smaller than screen size).

Christoph

-- 
POV-Ray tutorials, include files, Landscape of the week:
http://www.tu-bs.de/~y0013390/ (Last updated 24 Jul. 2005)
MegaPOV with mechanics simulation: http://megapov.inetart.net/

Post a reply to this message

Nicolas Calimet wrote:
>     A new version of the Linux framebuffer patch to povray-3.6.1 for Unix
> is available for download here:
> 
> http://pov4grasp.free.fr/download/povray-3.6.1-fb-0.2.tar.gz
> 
>     This version 0.2 aims at supporting all color depths (bpp) and fix
> some of the problems found in version 0.1 released almost a year ago; see:
> 
> http://news.povray.org/povray.unix/thread/%3C4132ac2b%40news.povray.org%3E/
> 
> 
>     The list below summarizes the changes from version 0.1 to version 0.2:
> 
> - the fbdev.* source files are renamed to the more generic fb.* in order to
>   avoid confusion with the fbdev driver from XFree86.  Please remove the 
> old
>   fbdev.* files before applying this patch.
> 
> - add proper support for 8, 15, 16, 24, and possibly 32 bpp color depths
>   and at any screen resolution (tested at 640x480 and 1024x768 using the
>   vesafb driver).  32bpp color depth was not tested but is believed to
>   work as well as the 24bpp mode.  Please report any problem otherwise.
> 
> - the 8bpp mode (256 colors) has two different color palettes implemented:
>   a generic 216 color palette (aka "web" palette made of 6x6x6 colors) and
>   a slightly better 240 color palette (5x8x6 colors) which should somewhat
>   limit dithering artefacts.  The 240-color palette is the default; the 
> "web"
>   palette can be selected at compile-time only, by setting the USE_COLORMAP
>   definition at the top of unix/fb.cpp.  A 240-gray-level palette is also
>   available when one specifies e.g. "Palette=G" in the povray.ini file.
>   Note that 240 custom colors are the maximum available, since the 
> remaining
>   16 colors are kept unchanged to avoid ugly color flickering effects at 
> the
>   console (these are the default system colors).
> 
> - the 15, 16, 24 (and 32) bpp modes do not use a color palette and give
>   very similar visual results.  In version 0.1 only the 16 bpp mode would
>   work correctly.
> 
> - the patch now honors the FRAMEBUFFER environment variable, or uses 
> /dev/fb0
>   as the default framebuffer device otherwise.  There's also no more 
> possible
>   interference with the svga display.  There is _still_ possible 
> interference
>   with a X Window session running on top of the framebuffer console (see
>   the old threads linked above for more detail on this topic).
> 
> - the console state with respect to keyboard input is now properly restored
>   whenever the render is stopped.
> 
> - version 0.1 had a "hidden" (undocumented) feature which allowed to dump
>   the screen to a PPM file.  Press the 'q' key at any time during the
>   rendering stage to output a dump.ppm file in the current directory.  Note
>   that this feature does currently bypass the IO-restriction scheme and is
>   therefore "dangerous" - use at your own risk.  It will be slightly 
> reworked
>   in the future.
> 
> 
>     To apply the patch, untar the archive and copy all the files from
> the newly created povray-3.6.1-fb-02/ directory to the corresponding 
> locations
> in the source distribution of povray-3.6.1.  Then run the ./configure 
> script
> as usual, and 'make check' to build and run a test render.  The tarball 
> provides
> only the new and modified files, as compared to the official 
> povray-3.6.1 for
> Unix source archive.
> 
>     See p.binaries.images for examples at all supported color depths.
> The images were obtained using the dump screen feature mentioned above.
> 
>     - NC

Great!
I'll give it a try (within the next weeks).

Sebastian

Post a reply to this message

> Are you sure the vga environment variable is the right way (tm) to 
> detect a framebuffer display?

	No  :-)
	In fact I completely forgot to check again that part in unix.cpp.
The test for the vga environment variable was added long ago (soon after
I released 0.1) but then I flipped over that part.  Anyway, if no frame-
buffer is available, povray will Error() when trying to setup the display.
Obviously a better test should be done earlier though.

> Note for higher 
> resoluation modes it could be nice to have the option not to center the 
> render view but put it in the upper right corner

	I plan to use additional environment variables (or maybe* fb-specific
command line options, similarly to the X Window-specific options) to let
the user offset the preview anywhere.  Additionally I'd like to let the
preview display go to another terminal; I don't know yet whether it's
possible or not (my first tests are not so encouraging).  Also, with fb
drivers that support it: on-the-fly change of the screen resolution to
better fit the image size (would be nice in conjunction with the previous
planed feature).  But at the moment I can't test the later: vesafb does
not allow me to do so, and I'm not able to use another driver.

	FYI version 0.3 will also deal with alpha transparency a la xwin.

	- NC

(*) IMO env. vars are more handy: no need to set them all the time

Post a reply to this message

> - version 0.1 had a "hidden" (undocumented) feature which allowed to dump
>   the screen to a PPM file.  Press the 'q' key at any time during the
>   rendering stage to output a dump.ppm file in the current directory.

	Correction: pressing the 'q' key will abort the render (if +x or
Test_Abort=On are set).  To dump the screen, press 'd' while rendering.
The rendering will pause a fraction of a second - the time required to
write the file on disk.

	- NC

Post a reply to this message