[AddOn] Monster Tile Renderer (update 15-Aug-'12)

To make this platform independent do:

>>> import os
>>> foldername_containing_images = ‘my_unstitched_images’
>>> os.path.join(os.getcwd(), foldername_containing_images, ‘’)
‘/home/zeffii/my_unstitched_images/’

tahseen, OK it works on the official build within one or two weeks I think we’ll see a new official release of 2.64 and for this the script will need some fixing.

Sorry, couldn’t get what you mean by this posting

In the github repo, file
stitch_images_23.py is for python 2.7 with PIL. This file represents an older version of the stitcher.
This is also the version for which your short tutorial makes the most sense, with respect to paths.

Some time later I made a few adjustments, resulting in a version bump to
stitch_images_24.py which uses python 3k, and PIL built for 3k.

Stitch 24, is a script that you can stick into the directory that contains the pngs and run from there, it will ignore the .py and process only .pngs. Naturally even this approach is not very convenient or obvious.

So is it that it can work only for PNGs? Not JPGs?

I think PIL is a little agnostic as to what the input is, you can change the


output_format = 'PNG'

to some other PIL supported type.

If i’m not totally mistaken the only other change, if you want to output something other than PNG is


comp_image.save(path+'somefilename'+'.'+output_format, format=output_format)

or alternatively


output_name = 'some_output_filename'
extention = '.' + output_format.lower()
filename = output_name + extention
comp_image.save(path + filename, format=output_format)

EDIT: yikes, I had forgotten how to use the Addon. If no camera is present when hitting ’ do render job’ Blender quits without message. This will be fixed asap.

redundant post now.

I’ve restructured the stitcher code for python 2.7, it is available here
(it includes instructions if you simply run python autostitcher.py)

@bashi, i will need to experiment with network rendering before adding support for that. if you have ideas (or working code) please share it might speed things up a little.

To those looking for Cycles support of Monster Tile Renderer, i think (unconfirmed) Brecht is implementing some tile rendering approach of his own for Cycles.

Hi zeffii,

i really just replaced

bpy.ops.render.render()

by

bpy.ops.render.netclientsendframe()

(not sure if the save mainfile is from me or already in your code…)

(It just send it to network instead of Render it.)
This worked out of the Box, if you establish a Network in Network Renderer First.

Maybe just add a switch for Render/Network. I have to look at the Code again and have to say i’m new to python. :wink:

thx

hi,

I’m run stitch_image_24.py through python 32 + PIL and get the nice result.But in the middle process, the default image editor sudden open.Is there anyway the processess on the background w/o editor opened.

Thanks in advance.

Sure, you can uncomment (stick a hash symbol in front of)

# comp_image.show()

It works.Thanks @zeffi.

Hey zeffii! :smiley:

It’s only just finally dawned on me why “couldn’t acquire buffer from image”! - it’s because that part of the code executes before the render has time to complete.
You’ll have to use some polling/testing, and/or perhaps appending to the render_complete callback.

I’m still having difficulties getting Blender to do multiple renders manually, so I have no help for you at the moment unfortunately. It keeps telling me that the render.poll() context is incorrect - whatever context that happens to be! What’s worse is I have two addon ideas that are being stumped because of this.

Anywho, your addon’s pretty sweet. I’ll have to play around with it!

Let me know if you find a solution to the rendering issues! :slight_smile:

Ok this may seem like and obvious and stupid question,but what does this script do?

Simply put: it breaks up the render into several tiles, allowing you to render at a much larger size with ease. For example; a 1024x1024 render could become 4096x4096, or larger.

There is also a “stitch” addon, which combines the rendered tiles into one image. I’m not sure where to get that, but I know it’s mentioned in some previous replies to this post. :wink:

Ok so it will “copy” a 1024 X 1024 render from blender and make it into 4096 X4096 seamless image so you can tile it?

Sorry, I see my explaination can be misleading. :stuck_out_tongue:

It doesn’t copy a render, it actually renders each tile there and then inside Blender. :slight_smile:

So it can basically split a 10k x 10k render into 100 lets say smaller squares and render them individually then weld them together into the final image ? does it work with GPU ?
I mean don’t the smaller pieces look weird when they are welded into the bigger image ? like a puzzle effect ? or you don’t see where they have been joined ?
Also is this done automatically ? no manual work involved ?

Ok after looking at the github page I get it now. That image on that page was worth a thousand words :slight_smile:

no idea, it doesn’t work with cycles yet. Logically region rendering should work with cycles too, eventually.

There are situations where you might notice the stitch line, for instance if you are using an unseeded noise as a texture or bump deformer and not rendering the image in one blender session. (ie new sessions might have different random values and not match older sessions). The solution is to use a seed, which is good practice anyway.

If you have ever seen a billboard being posted they are put up in strips, because there are few (inexpensive) printing techniques that produce prints of more than 2 or 3 meters wide.

The ‘stitching’ is done by a script, running the script is the last manual step. but all you have to do is point the script at a folder of unstitched images and it will join them (if your computer has sufficient ram)

Ok thanks for clearing that up !

In regard to my question about GPU rendering with the monster tile render. I don’t think there would be actual benefits in terms of rendering speed no ? maybe only saving up ram … but gpu rendering doesn’t use much ram anyway, compared to CPU biased techniques.