Backburner Strip Problem

Become a member of the CGSociety

Connect, Share, and Learn with our Large Growing CG Art Community. It's Free!

THREAD CLOSED
 
Thread Tools Search this Thread Display Modes
Old 06 June 2013   #1
Backburner Strip Problem

Howdy gang,

In the face of both logic and the advice from almost literally everyone, I'm persevering with Backburner and it is, predictably, proving more distressing than a cat in a bag hearing the wheels descend into that familiar pot-hole on the way to the big bridge.

The specific problem this time is... well, somewhat sporadic, but when it comes to Backburner, what isn't, frankly? I'm using BB2014 and Max 2014.

The first problem is when rendering .EXR's, the stripped output (both main RGBA and any render elements) comes out black. The strips themselves, if I tell BB not to delete them, are FINE. They are totally kosher, alpha and all. But the stitched together ones are totally black. The really odd thing is that they have file sizes - and different ones from one another, at that. They are more or less what you'd expect for losslessly compressed files - the RGB is the biggest, along with the reflection passes. Alphas and masks are the smallest. But when you pull them into Photoshop, AE, Nuke, back into Max etc, they're all black, in the RGB and the Alpha. But again, the strips themselves are fine, so I think it's a problem with the stitching itself.

As a secondary problem, sometimes when we're rendering .tif's (but not always), the passes that aren't the main RGB come out black and white. They look perfect, except they're only greyscale. Despite only being 16bit in the render output window (and the main RGB being 16 bit and behaving as such), when these greyscale images are brought into Photoshop, it interprets them as 32 bit. 32 bits of black and bloody white! However, this is also the case in the strips themselves, not just the stitches, so I think this might be a bizarre VRay problem that's just a coincidence.

So... any ideas, chaps?!

Edit: As a few things I've tried...:

- Short file paths
- Long file paths
- Trailing '_'s
- A lack of numbers
- A lack of separator characters ("-","_"," ")
- It even happens when I just make a teapot in a new scene and render it off. Again, the data appears to be there, but I can't seeeeee it.
__________________


Last edited by DanGrover : 06 June 2013 at 09:27 AM.
 
Old 06 June 2013   #2
This may sound odd but try putting a small coloured box at the top left corner of your render...
It might be if the first strip has no data, then the stitcher analyses this and says well it must be a greyscale image etc.... I know Deadline had some issues with it for a while until I figured it out.

D

PS GO TO DEADLINE!!! Backburner makes me feel physically ill inside thinking about it!
__________________
Maxscript Made Easy...
http://davewortley.wordpress.com/
 
Old 06 June 2013   #3
Originally Posted by DaveWortley: This may sound odd but try putting a small coloured box at the top left corner of your render...
It might be if the first strip has no data, then the stitcher analyses this and says well it must be a greyscale image etc.... I know Deadline had some issues with it for a while until I figured it out.

D

PS GO TO DEADLINE!!! Backburner makes me feel physically ill inside thinking about it!


This sounds like exactly the kind of batty solution that might actually work. That said, it's not relevant for the latest EXR problem (purely because the latest failed render that inspired me to make this post has 100% full on pixel coverage), but for the grey tif problem, I'll give it a go!

And re: Deadline, yeah, we actually had it at my last place (ask Zsuzsanna!). I love it to bits. That's a fight I'm thus far failing to win...
__________________

 
Old 06 June 2013   #4
I had the same problem last week and I finally realized that the exr setting was in Half Float (16bit/channel) instead of the Full Float (32bit/channel)
image was created, large file size, but black content

changing back to Full Float solved the problem

funny thing: it was not even possible to open the image via the 3dsmax file viewer (what's the point of keeping a setting if you can not use it, even with the application that created it ?)

I hope it will work for you
 
Old 06 June 2013   #5
Originally Posted by FLUCA: I had the same problem last week and I finally realized that the exr setting was in Half Float (16bit/channel) instead of the Full Float (32bit/channel)
image was created, large file size, but black content

changing back to Full Float solved the problem

funny thing: it was not even possible to open the image via the 3dsmax file viewer (what's the point of keeping a setting if you can not use it, even with the application that created it ?)

I hope it will work for you

Thanks for the suggestion, Fred! I'll give it a go now.
__________________

 
Old 06 June 2013   #6
Boo I'm afraid that didn't work. Same problem - the strips are fine, the renders are black (only now they're black and huge, aha). Thanks for the suggestion, though!
__________________

 
Old 06 June 2013   #7
I am sorry if it didn't work
at least, thanks to you, I have discovered the split render option
usually I use the bucketrendering or blowout region for big renders, but for the latest you have to stitch each image element
why are you using the split rendering ? is it for still image or video ?
 
Old 06 June 2013   #8
Originally Posted by FLUCA: I am sorry if it didn't work
at least, thanks to you, I have discovered the split render option
usually I use the bucketrendering or blowout region for big renders, but for the latest you have to stitch each image element
why are you using the split rendering ? is it for still image or video ?


It's just for a large render. The machines can do them on their own, but we have about ~8 or so in our small farm, so splitting them up and rendering in strips is a lot quicker. We could just use Distributed Rendering and get a similar result (without the problem!) but there's no good (or easy and fair) way of telling backburner not to give them a job whilst they are busy with a distributed job. As such, you may start with 8 machine's buckets on your render but then they all grind to a halt and you realise someone has sent a render to Backburner not realising I was using Distributed Rendering. Then you find THAT render crashes because it effectively has both max files open in RAM etc etc.
__________________

 
Old 06 June 2013   #9
I understand
in that case rendering with blowout region works fine with backburner and its versy easy to stitch in photoshop
last week I renderered 12000x6750 images in four parts with several passes in one night for a total of 49hours calculation
counterpart is to be very methodic when you start the render
and I still don't get why by default the 600minutes time out is active even when you don't enable it in the advance settings
 
Old 06 June 2013   #10
Thread automatically closed

This thread has been automatically closed as it remained inactive for 12 months. If you wish to continue the discussion, please create a new thread in the appropriate forum.
 
Thread Closed share thread



Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
CGSociety
Society of Digital Artists
www.cgsociety.org

Powered by vBulletin
Copyright 2000 - 2006,
Jelsoft Enterprises Ltd.
Minimize Ads
Forum Jump
Miscellaneous

All times are GMT. The time now is 10:54 AM.


Powered by vBulletin
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.