And in three out of the four times, this black square appeared in the render. The first, second and fourth time... Third pic I made, with the exact same hair, skin, light, camera, everything.. the square was absent. Third time lucky I suppose.

Has anyone seen it before? Or anything like it? It looks like it might be related tot he black streaks in Pre SR1 but I'm not sure.

The background is pjz's render room.

And yes. Poser 8. SR1 applied.

As it is here, it's easily postworked away, but if I'd had a patterned background like a brick wall or something, it would have been more annoying.

And why doesn't it happen EVERY time?! 

I had that several times before SR1.  Not since..

It is a bug, I posted a bug report on it weeks ago, it's never been reproducible, and it isn't fixed yet. I hardly ever see it since SR1 - maybe once. If you have a scene that can make it happen more than one in a thousand renders, maybe SM should have that scene.

Trouble is, these scenes often have copyright content in them, such as V4, so I don't give them to SM, under the assumption that I'm not allowed to. Maybe I'm mistaken and it is allowed. Further, I'm sure somebody at SM already has V4. But I don't know what is permitted.

That's a flaw in CG copyright, IMO - I should be able to give a copyrighted content item to SM for them to reproduce a bug in the software. There should be some "bonded vendor" notion, where, similar to a Non-Disclosure Agreement, they are legally allowed to receive the copyright content for debugging purposes, and then delete it.

Quote - Trouble is, these scenes often have copyright content in them, such as V4, so I don't give them to SM, under the assumption that I'm not allowed to. Maybe I'm mistaken and it is allowed. Further, I'm sure somebody at SM already has V4. But I don't know what is permitted.

The problem with PZ3s isn't usually the geometry for figures (this should be an external call to the OBJ) or textures (always external references), but the geometry for props (which is internalised) and morph data (when internalised).

If you can still get the bug to show up when all morphs have been dropped (relatively easy) and no textures applied, then you only have to worry about SM having a copy of the figure OBJ.
I suspect the real problem is that the occurence of the bug is too dependant on everything being "just so", which means your left with trying to get it to appear with only the content supplied with Poser.
The other approach is to review the code asking the question "What could cause a bucket to return nothing or cause it to fail to return anything ?"

I give copyrighted content to app makers to help them debug... And they promise to use it only for testing... But I wear a funny mustache in case the feds are watching

 Well the scene consists of only freebies. Readily available, so I doubt there would be any problems in sharing the scene. Antonia is free, as are the textures. The hair is free dynamic hair and pjz donated the Render Room. And I made all the morphs myself. Soooo.... I'd say it was safe to send on. BB, where can I send this file? Attach it to a ticket? It made the error consistently in three out of four renders in a row.

 Oh and I used D3D's RenderFirefly script to render it. Are those settings also saved in the PZ3?

They are saved I think. I dont know how they handle this with non-beta testers. Just open a ticket, because not one beta tester was able to make this happen at will or close to it.

(Coincidentally, I had a black bucket today ONCE - first time in ages.)

I used to have a similar problem in P7 firefly: There would be bucket-sized holes in the image in the alpha channel, usually in a streaking pattern. I discovered that these 'holes' were patterned on geometry that was behind the camera. They finally fixed it with SR-3.

Until SR-3 I could avoid the problem by making sure no props, figures, or other geometry like lights were behind the camera or intersecting it. If nothing is behind the camera and these 'bucket holes' still happen to you then I would guess it is a different problem, though it seems very similar.

Quote - Trouble is, these scenes often have copyright content in them, such as V4, so I don't give them to SM, under the assumption that I'm not allowed to. Maybe I'm mistaken and it is allowed. Further, I'm sure somebody at SM already has V4. But I don't know what is permitted.

When I was having this problem I sent an example scene to E-Frontier using the 'collect scene inventory' script -at tech support's request- which had some non-E-Frontier props in it (they knew it contained content from a different company). I was under the assumption that sending content in this manner to Poser tech support for bona fide debugging research is a very rare occasion when giving copyrighted material is legitimate. I would also assume that Poser tech support would act ethically and only use the scene and content files to resolve a customer issue and not for any other personal or commercial use.

Could be, but consider what happens when these bugs are entered into bug management during beta testing. The bug tracking system is open to beta users, who are able to see each others bug reports. This was not so in the past, and every bug was a private matter between the reporter and SM. But that was always unwieldy. The bug system needs to be a community, so that when I see you reported a bug, 1) I don't make a duplicate for no reason and 2) I can participate in comments on your bug, like adding more ways to make it happen.

But the upshot of this is that when I make a bug report, whatever I attach is visible and downloadable by all beta users.

I see, when I was dealing with this a year or two ago, and it was E-Frontier at the time, I was working one-on-one with my tech support guy to the best of my knowledge. I'm unfamiliar with how SM currently handles its tech support, which is lucky on my part.

There ought to be a way for Smith Micro to get scene files like this for legitimate testing and user support reasons without making them available to the world. Due to the nature of Poser and content typically coming from a variety of sources, all protected by copyright, this won't be the last time this issue will come up.

I would say that if SM wants to look at this file then mention your copyright concerns with them before uploading to them.

 Again in this case there IS no copyright concern as I see it. Everything is available free of charge, so whether I send it to SM or they go download the stuff themselves and recreate the scene - same thing.

So I attached my scene to the ticket and sent it off.

Strangely enough when I tried to make it happen once more before sending it, the hole was there - in the IDL pass, but when the final render had passed, it was gone. I wrote that in the bug report as well of course.

Is your preview background black? I mean the Poser background. When i have those squares, they're not black but grey, same color as my background...

 Hm. Usually I don't change it. But I'm not sure if I chose "Render over Black" this time. I think I might.

But the preview is the usual grey. And everything is enclosed in pjz99's render room thingie - so the background shouldn't be visible at all anyway...

I have this happen all of the time during animation. I solve the problem by removing the erroneous frame and that's all I can do. I have been in touch with SM since before the SR1 release and Cazky... I think was his name, was very interested in it, as well as stumped by it. It looks like the same issue that P5 and P7 had (don't know about P6, never bought it). For those who had this occur in the earlier editions of Poser, some of you remember that you didn't need to have geometry behind the camera for this issue to occur, though it was the most reported reason. This is probably the same thing and it will probably get fixed soon. 

My problem seems to occur the most when rendering sky domes. It's easy to work around but I think that SM is working on this diligently and the above mentioned tech was rather concerned and had sent off a report to the program team that day, they just didn't have an answer before SR1. I would bet it will be fixed in SR2. Even though they are aware, send them the report of your bug anyway. It lets them know how wide spread the issue is and what similarities there are between computers experiencing the issue.

And, before anyone jumps on it, this occurs whether I use the animation renderer or render to tif's.