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

Nicolas Calimet wrote:
> 
>     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...

Well - with Imagemagick you can specify 'magick:LOGO' (or 'LOGO:' in old 
style syntax) as file name to obtain the internally generated logo 
image.  Same for other images or patterns like 'pattern:checkboard'.

So when POV-Ray has a command line option -background <file> just use 
something like -background internal:TRANSPARENT

I know there currently is no such option but it could be introduced 
(alternatively/additionally an environment variable).

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