|
|
|
|
|
|
| |
| |
|
|
From: Nicolas Calimet
Subject: Linux framebuffer patch version 0.2 released
Date: 12 Aug 2005 16:23:20
Message: <42fd0538@news.povray.org>
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
From: Sebastian H
Subject: Re: Linux framebuffer patch version 0.2 released
Date: 13 Aug 2005 06:41:51
Message: <42fdce6f@news.povray.org>
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
From: Nicolas Calimet
Subject: Re: Linux framebuffer patch version 0.2 released
Date: 13 Aug 2005 13:31:40
Message: <42fe2e7c$1@news.povray.org>
|
|
|
| |
| |
|
|
> 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
|
|
| |
| |
|
|
From: Nicolas Calimet
Subject: Re: Linux framebuffer patch version 0.2 released
Date: 13 Aug 2005 13:41:02
Message: <42fe30ae@news.povray.org>
|
|
|
| |
| |
|
|
> - 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
|
|
| |
| |
|
|
|
|
| |
|
|