Has anyone else noticed that frames that fail to render when written straight to disk will often work fine when rendered to iplay instead.

Anyone got any ideas why? What does iplay force mantra to do that is different and can it be made to happen when mantra renders to disk?

The main difference is in the way the bucket order is done and how Mantra caches those buckets.

Interactive mplay renders will whirl around in a clockwise fashion around the current center of interest (0.5,0.5 center or where you last clicked your cursor).

Rendering to disk will always render from bottom left, row by row until done.

Now mantra will cache all previous buckets on the same line as it marches across from left to right. When it finishes the line, it flushes the buffers and starts again on the next line, cahcing all previous buckets on the line.

Now mantra should unload buckets as the memory is being filled across the line.

In Houdini8, there are new options to force interactive mantra to render with the same behaviour as when rendering non-interactively to help users with this and other issues related to the way buckets are accessed.

Now for your specific problem.
What errors does mantra report when it fails?

That's the problem it doesn't report any errors it just gives up.

What would be nice in H8 is for the reverse option, so that we can make mantra to disk create and store buckets the same way ip mantra does since it seems to do a better job.

I also have an issue when rendering print res images to disk where mantra just won't even generate a single pixel, however rendering to iplay is fine.

And the final twist, some iplay renders will give up eventually too, so I end up rendering several versions by clicking on different bits of the image and then comp all the jigsaw pieces back together.

In all these cases splitting the image up with crops in the camera settings sometimes helps too, it's just time consumming to set up and test, but it just seems weird that iplay deals with the frames inherently better.

From what you are saying it must be something to do with loosing the cache?

You mentioned print-sized renders. That means huge texture maps if you are using them. If those textures are rendered with Mantra and they are NOT .rat files then mantra will have to load the whole darn map in to memory when redering the first bucket that access a surface with a shader that calls for that map. Obviously gets worse the more textures you use. Whenever I hear of “stalled” renders on the first few buckets I immediately suspect large textures that are not .rat's.

Need to use .rat files in order to get the benefits of only loading in the part of the texture that fits in to the current bucket. You also gain with the reduced resolution with the ability for mantra to access the different mipmap levels.

In some ways I like the brutal approach that RenderMan had with only allowing .tx files as texture maps. Yes I know that RenderMan V9 and above now allows you to use tif's and get the mipmap levels and such but I still find that users prefer to use .tx files for their maps.

All our textures are procedural, the only texture map we use is for the iris.
That way we can render images the size of a house and they are still sharp.

must get round to writing a procedural iris shader……