Inside Sabertooth
Learn how Sabertooth uses 3ds Max to create 3D interactive projects, including HBO Go’s Game of Thrones interactive experience
  • 1/3
You are here: Forum Home / Autodesk 3ds® Max® / Autodesk 3ds Max / 3ds Max Design 2009 / Backburner not stiching strips of images over 7000x7000pix
  RSS 2.0 ATOM  
2 pages: 1.2 first

Backburner not stiching strips of images over 7000x7000pix
Rate this thread
 
21172
 
Permlink of this thread  
avatar

Not the problem the strips come out like
_STP00000_BEN0000.jpg and the first number increments as expected.
Every seems to be fine except the stitch which is what I can’t get my head around, also the error message
‘Error creating Output Image” doesn’t help in the slightest as all the strips render as expected to the same network resource.
Also images under 7000x7000 don’t get the message and complete.
I mean 7000pix at 300dpi is only 23” or 600mm and thats not a big image in my book when we produce double A0 prints often.



Replies: 0
avatar
  • Samab
  • Posted: 12 January 2009 10:01 AM

OK I don’t have a definitive answer to this. But it seems obvious that Max has memory issues with hi res renders looking at these treads:-
http://area.autodesk.com/for...-get-fired-today/Page-10/
http://area.autodesk.com/for...m-than-previous-versions/
http://www.mymentalray.com/forum/showthread.php?t=275
I know these are not the same problem as you but reading them, it seems like you the render gets done, but the final output of the file fails because of memory.
So possible solutions may be, memory optimisation, like this:-
http://www.neilblevins.com/cg_education/reducing_memory/reducing_memory.htm
a lot of that is specific to mr, what renderer are you using? If it is mr, then DBR may work better than BB strips.
Are you using the /3GB switch, to access more of your 4GB?
Maybe the move to 64-bit is worth considering:-
http://area.autodesk.com/for...hing-from-32bit-to-64bit/

One thing I never thought about before with strip rendering is, where is the final image stitched together? Because that is likely where you problem stems from. To create a singe image file, the strips must all go to a single machine that completes the process, is it one of the BB Servers (which one?) or the manager? That’s where you have to look.
If it is the manager, well in some farms the manager is not an active renderer running server, it just assigns tasks to others and therefore may not be upto the same spec. Don’t know if that’s the case with your farm.



Replies: 0
avatar

Cheers Samab,

Renderer we generally use is VRAY but on these tests I have left it set as Default ScanLine render and also tried VRAY.
The stitching can be done on any of the render nodes they are identicle and it will try all of them one after the other if it fails to complete.
The Manager is a lower spec box but only deals with passing the jobs out nothing else (maybe monitor too).

I am pretty sure you are right but it doesn’t really make sense.
I can submit the same job as tiff and jpeg
The jpeg strips are in the order of 250k per strip and it will fail but in tiff with strips in the order of 60mb it will succeed (at slightly lower res mind)
The stitcher must get the strips in the format they were created therefore jpegs will be 2.5mb worth and the tiff 600mb.
if it were a memory I would have to assume that you would never be able to stitch 10 X 60mb files if you couldn’t stitch 10 x 250k files.

Thanks for the pointers, if you have any other thoughts I would greatly like to hear them or the IT dept will be rebuilding the farm as Max9 (which I dont really want to).



Replies: 0
avatar
  • Samab
  • Posted: 12 January 2009 11:18 AM

Having now actually tried BB strip rendering, I see your point. My last comment about the stitching machine seems a bit of a no-brainer, having seen how it works, doing a second pass on one of the servers.
I was making assumptions about how I thought it would work (or should work).
I rendered a 8000x8000 PNG image to 20 strips, it went with without a hitch. I see that it saves the strips to disk in the (PNG) format before assembling them. I assumed it would retain the data in the raw frame buffer format and assemble that, then encode to the output filetype. That way would avoid going two generations of compression with Jpegs and other lossy formats, but would likely need more memory.
You said Tiffs work OK, have you tried saving different formats like PNG?
Doesn’t Vray have a DBR system, that would be an option?
Not what you want, but you may have to manually stitch the strips in PS, or maybe someone has a script/PS Action that will do it for you.
I’ve heard Deadline does a better job of stitching than BB, another option maybe.



Replies: 0
avatar

I need to try PNG its used alot, I just went for the 2 that had vastly different file sizes if you see my thinking.
VRAY has its own but it doesn’t have any management or queue system, it multiple users attack the farm it actually slows it down so not ideal in any way.

Tiffs work to a point around the 7000 pix area too I was just trying to demonstrate that it didn’t look like a memory problem.
The scene is just 20 teapots no textures or lights.

Deadline would be nice but current market conditions force the - No Cost option.
I could try and write a PS action though as an interim.

You see how it doesn’t make sence though as its just a stitching routine and should really have any problem. Its baffling......



Replies: 0
2 pages: 1.2 first