POV-Ray

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.

Tasklist

FS#282 - Unrendered region should be transparent, not black

Attached to Project: POV-Ray
Opened by Timwi (Timwi) - Sunday, 24 March 2013, 13:12 GMT
Last edited by William F Pokorny (wfpokorny) - Friday, 21 April 2017, 11:30 GMT
Task Type Feature Request
Category Frontend → Image format
Status Tracked on GitHub   Reopened
Assigned To No-one
Operating System All
Severity Low
Priority Low
Reported Version Not applicable
Due in Version Future release
Due Date Undecided
Percent Complete 0%
Votes 2
Private No

Details

When rendering only a region of a file, using the command-line options +sc/+sr/+ec/+er, the area of the image that is excluded comes out as black in the final PNG.

Expected behaviour is for it to be transparent.

This task depends upon

Comment by Thorsten Fröhlich (thorsten) - Sunday, 24 March 2013, 14:28 GMT

The behavior is expected. The pixels are never filled, as you explicitl requested them to not be renderd. The background in a scene only applies to pixels rendered.

Comment by Timwi (Timwi) - Sunday, 24 March 2013, 20:54 GMT

This report is not referring to the background in a scene at all. The unrendered region should simply always be transparent — after all, as you correctly pointed out, it is not rendered. It should not be filled with black.

Please reopen as the closer misunderstood the bugreport.

Comment by Thorsten Fröhlich (thorsten) - Sunday, 24 March 2013, 21:00 GMT

Did you read the response to your report 283?

Comment by Timwi (Timwi) - Sunday, 24 March 2013, 21:19 GMT

Report 283 is completely unrelated to this one. Report 283 is about “background { ... }”. This one is not. This one is about +sc/+sr/+ec/+er.

Comment by Timwi (Timwi) - Sunday, 24 March 2013, 21:21 GMT

But to answer your question, yes, I read it, and I tried +UA, and it still comes out as opaque black.

Comment by Christoph Lipka (clipka) - Sunday, 24 March 2013, 22:30 GMT

I think it is reasonable to expect unrendered portions of the image to come out transparent when alpha support is enabled for the output file. After all, the preview window also still shows the checkerboard pattern in those regions. I therefore re-opened this issue as a feature request.

Comment by Thorsten Fröhlich (thorsten) - Monday, 25 March 2013, 07:55 GMT
I think it is reasonable to expect unrendered portions of the image to come out transparent when alpha support is enabled for the output file. After all, the preview window also still shows the checkerboard pattern in those regions. I therefore re-opened this issue as a feature request.

I agree, it would be a useful feature. Of course, we had been discussing if we want a full image generated for a partial render or not for a long time anyway. Once we add a choice for that, we can also change the current behavior.

Comment by Simon (infoised) - Tuesday, 26 March 2013, 18:36 GMT

Just an opinion to consider: outputting a partial render with transparent unrendered parts can be extremely useful. In cases when a small part of the image changes, and the rest stays the same (this is ok if there's no radiosity and reflections), rendering speed can be significantly increased if only the changing part is rendered, and then the partial image is composited over a single render of surroundings. Let's say, a render of animation that includes a rotating or morphing object in static environment (common in scientific presentations). Having a transparent background makes the compositing a trivial operation. The same technique can be used to distribute rendering across different machines (such as ad-hoc cluster over ssh): chunks can be easily merged if the unrendered parts are transparent.

Comment by William F Pokorny (wfpokorny) - Friday, 21 April 2017, 11:30 GMT
  • Field changed: Status (New → Tracked on GitHub)

Now tracked on github as issue #279.

Loading...