The Persistence of Vision Raytracer (POV-Ray).

This is the legacy Bug Tracking System for the POV-Ray project. Bugs listed here are being migrated to our github issue tracker. Please refer to that for new reports or updates to existing ones on this system.


FS#27 - Add texture support to background statement

Attached to Project: POV-Ray
Opened by Thorsten Fröhlich (thorsten) - Saturday, 16 May 2009, 17:15 GMT
Last edited by William F Pokorny (wfpokorny) - Saturday, 10 December 2016, 14:39 GMT
Task Type Feature Request
Category Backend → Other
Status Tracked on GitHub
Assigned To Thorsten Fröhlich (thorsten)
Operating System All
Severity Low
Priority Normal
Reported Version 3.70 beta 32
Due in Version Future release
Due Date Undecided
Percent Complete 0%
Votes 1
Private No


Adding full texture statement support to the background statement (with a scale of 1/1) aligned with the image_map direction of an image would allow i.e. specifying an image as background easily.

This task depends upon

Comment by Christoph Lipka (clipka) - Wednesday, 20 May 2009, 14:43 GMT

This would be inherently problematic with reflections/refractions and radiosity.

Maybe a better alternative would be to introduce a new image projection type, equivalent of replacing the camera with a projector, which could then easily be used with a sky_sphere (or even arbitrary geometry, which could provide tremendous potential for rendering stuff into existing images).

Comment by Grimbert Jérôme (Le_Forgeron) - Thursday, 24 September 2009, 19:02 GMT

what seems behind the initial query would be to automatically compose an existing image as being behind the rendered scene (whenever alpha reach 100%)
Only side effect would that the rendered image has coordinates in <0,0>/<1,1> and that should match the space of the background image (so it could get stretched if ratio are different)

For reflections/refraction & radiosity, I guess that out of view value is irrelevant, and as such the image could be a "replacement" (or rather a bonus) to the actual background colour.
In fact, the texture is irrelevant, only the pixel image is important (with a possible gamma correction at reading, and same anti-aliasing).
Finish is irrelevant. Normal is irrelevant.
A simple pigment_map would be enough (without transform)

A projection type would failed with normal-perturbed camera.

Now, what about, for the original querier, to use a no_reflection, no_shadow, ambient 1 diffuse 0, flat box orthogonal to the camera (MEEEPPP, fails on normal-perturbation of camera) in the very back of the scene, with image on it ?

Or use the omni-present imagemagick as post-process command of povray to perform the composition.

Only real need would be to avoid ruling of IRTC... do we need to turn povray into gimp for such purpose ?

If done as a bonus to current background colour, it could be "easy" to do it in the file-saving/transformation, when all data has been generated.

Comment by Grimbert Jérôme (Le_Forgeron) - Sunday, 05 September 2010, 09:04 GMT

On second thought, if the intend of the Original Poster is to specify an image as the background, it's only a matter of using a 2D image composing software afterhand, rendering with +UA (and in a format that support alpha: +FN, +FT, +FC).
(well, seems to have already been my first thought too).

I would go now for a reject of that task.

Comment by William F Pokorny (wfpokorny) - Saturday, 10 December 2016, 14:39 GMT
  • Field changed: Status (Assigned → Tracked on GitHub)

Now tracked on github as issue #171.