The version 0.3 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.3.0.tar.bz2

	List of changes from version 0.2 to 0.3:

- add support for 15/16/24/32 bpp directcolor visuals (rgb colormaps)
- add support for (user-supplied) background image a la X Window
- add support for alpha transparency in rendering and background image
- add custom positioning of the display with $POV_FB_GEOMETRY
- fix info message for 32 bpp color depth reported as 24 bpp
- fix finished message sent to stdout instead of stderr
- fix dump screen to use povray iostreams
- more code reorganisation

	Notes:

- Directcolor visuals were tested with the rather old aty128fb framebuffer
   driver in 8/15/24/32 bpp color depths (16 bpp is handled as 15 bpp).

- The background image feature is similar to that found in the X Window
   display capability of povray.  Usage is explained in the doc/README.unix
   file of the official povray-3.6.1 for Unix distributions.  Basically
   the background behind the display is filled with a checker pattern by
   default, or the ~/.povray/3.6/background.ext image file (where "ext"
   is either "jpg", "jpeg", "png", "ppm", "tga" or "gif").  The difference
   here is that alpha channel is supported; thus an empty background can be
   obtained using a fully transparent (1-pixel) image.  Tested with png
   files only (transparency might not work with gif files yet).

- The display can now be arbitrarily positionned anywhere on- or off-screen.
   Its position and maximum size are controlled by the POV_FB_GEOMETRY
   environment variable, which value is in the form:
     MAXWIDTHxMAXHEIGHT+XOFFSET+YOFFSET
   where MAXWIDTH and MAXHEIGHT are positive integers to set the maximum
   display width and height, XOFFSET and YOFFSET are integers to specify
   the display offset compared to the screen borders.  The '+' sign can be
   replaced by '-' to tell which screen border to account for.  This notation
   basically follows the same rules as the -geometry option found in most
   X Window applications; see the X manual.  The difference is that the
   width and height set a maximum allowed size while keeping the display
   aspect ratio.

   For instance:

   export POV_FB_GEOMETRY=640x480-0+0
   povray abyss.pov +w2048 +h768

   will display the image with a maximum width of 640 pixels on the top
   right corner of the screen.

	Sample images are available in p.binaries.images (same subject).

	- NC

Post a reply to this message

Note: installation instruction (as for version 0.2)

	To apply the patch, untar the archive and copy all the files from the
newly created povray-3.6.1-fb-0.3.0/ 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 contains
only the new and modified files, as compared to the official povray-3.6.1 for
Unix source archive.

(From version 0.2 to 0.3 only the unix/fbb.cpp file was actually changed.
Thus it should be safe to copy that file alone if you already applied the
previous version of this patch to povray-3.6.1.)

	- NC

Post a reply to this message

Nicolas Calimet wrote:
> - add support for (user-supplied) background image a la X Window

You know i have been somewhat reluctant about the user supplied 
background (using the core code image reading functions for something 
there were't intended for...)

But of course using libxpm isn't an option here. :-)

Maybe we should just write a simple PPM reader that can be used by all 
display modes for reading the background image.

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

> You know i have been somewhat reluctant about the user supplied 
> background (using the core code image reading functions for something 
> there were't intended for...)

	... and you know that looking at the code will tell you that
those core functions aren't badly hijacked: it's actually quite clean
:-)

> Maybe we should just write a simple PPM reader that can be used by all 
> display modes for reading the background image.

	PPM can't handle transparency (gimp says).  Can it?

	- NC

Post a reply to this message

Nicolas Calimet wrote:
> 
>     ... and you know that looking at the code will tell you that
> those core functions aren't badly hijacked: it's actually quite clean
> :-)

Well - this is not the point.  The problem is that when making changes 
to the core code possible requirements of the frontend using the code 
for a different nonstandard purpose are no concern.  In other words: The 
interfaces between core code and platform specific frontend should be 
well defined for both directions and currently this is not the case for 
using the image reading functions in the frontend.

>> Maybe we should just write a simple PPM reader that can be used by all 
>> display modes for reading the background image.
> 
> 
>     PPM can't handle transparency (gimp says).  Can it?

No but what use has transparency except having a totally transparent 
image (which does not need to be an image anyway).  Note you can of 
course also implement a PNG reader but this would require libpng.

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:
> 
>     This patch is against pov 3.6, for which I doubt there will be any
> such core change.

For integrating this patch into MegaPOV we have to consider 
maintainability.  It is quite possibe that there will be patches 
changing the way images are read in the future.  To add some feature not 
actually extending program usability, just adding some gimmick, at this 
cost is not very good.  So when adding this patch to MegaPOV (which i 
seriously consider - the patch itself is a very interesting and useful 
one) i will most likely remove this part.

> 
>> No but what use has transparency except having a totally transparent 
>> image
> 
> 
>     That's precisely the point.
> 
> (which does not need to be an image anyway).
> 
>     I'd be interested to see how you would use the current background.*
> feature to get transparent background (apart from disabling the default
> checker code or adding support for some extra command / env var).

Quite simple: reserve a certain file name used for the background image 
to be interpreted as plain transparent.  Same can be used for different 
internally generated checkers.  See the ImageMagick built-in 
Images/Patterns for what i mean.

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

> For integrating this patch into MegaPOV we have to consider 
> maintainability.

	I knew you would answer something around these lines, which is one reason
that motivated the cancelling of my post.  But too late apparently  :-p

	- NC

Post a reply to this message

> Quite simple: reserve a certain file name used for the background image 
> to be interpreted as plain transparent.

	Not something I find particularly elegant either.

	- NC

Post a reply to this message

Nicolas Calimet wrote:
>> For integrating this patch into MegaPOV we have to consider 
>> maintainability.
> 
>     I knew you would answer something around these lines, which is one 
> reason
> that motivated the cancelling of my post.  But too late apparently  :-p

Just FYI: You have at most 5 minutes to cancel a post to prevent it from 
becoming visible for me (because i suck news every 5 minutes). ;-)

>     Not something I find particularly elegant either.

I find it a fairly good concept.  You can have any number of internal 
background patterns and the user has easy access to them without need to 
handle a separate file for each of them.  The background image 
reading/generation would be in the general code (in unix.cpp) and the 
different display modes would simply access them with some function.

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

> You can have any number of internal 
> background patterns and the user has easy access to them without need to 
> handle a separate file for each of them.

	I still don't quite understand how this would work from the user
standpoint (I'll look later at how imagemagick does) i.e. how the user
tell povray to use whatever image or pattern.
	Well probably too much coding of color bitmasks these last days...

> The background image 
> reading/generation would be in the general code (in unix.cpp)

	This is something I already wanted to do, so at least I agree
to this point  ;-)

	- NC

Post a reply to this message