I know there have been some other threads about this and I hope someone who has figured this stuff out will give me some help.

I'm running Maya 7 Unlimited and I want to set up a small render farm. I'm mostly interested in rendering very LARGE still mr images, 3K x 2400 pixels and bigger. I guess I need to set-up my PCs (running XP) on a network so the license on my laptop will let the renderer run? If I'm just rendering still images can't I just start them from the command line without resorting to other apps (I've seen Smedge mentioned)? Once the render is running can I pull my laptop (the one with the Maya Unlimited license) from the network without killing the render?

Also, I've come across memory issues where my renders crash because the file size is too large. I've done the 3 GB boot set-up and it just barely allows me to render at 3K x 2400 (right now I'm rendering on my laptop that maxes out at 4 GB of RAM). Will a PC with more RAM solve the problem or is there something fundamental about a 32 bit OS that just can't handle the large files? Do I need to go to a 64 bit OS to render larger? If I do go to a 64 bit Windows OS can I render mb files that were created on a 32 bit OS?

Thanks,

Matt

yeah 32 bit applications can the very best use 3GB with the large memory address flag

what you'll probably want to do is rather than try to render the image in one pass is break up the task in some way.. such as rendering quadrants

also if you want to render with mental ray on multiple machines you'll need to use the mr_satelitte .. offhand I don't recall how many nodes maya 7 will allow you to use

yes 64 bit systems can read files from a 32 bit system

could you describe what you are trying to render? It likely that there are other reasons that this isn't rendering that throwing more memory at won't solve.

Yes that would be the fact that a 32 bit register has a upper limit of 4294967296 (2^32) adresses it can point to after that its full. This is physical to the code andits embedded into each program. So that means a 32 bit system can never address more than that amount of memory. And thats exactly 4 GB. The operating system Reserves a fair amount of this for kernel work that is it gives each program a memory slice of this. So in practice each program has 1.5-3gb of working space.

And no there's NO way around this besides getting e 64 bit os thats a physical limitation. However please note 64 bit operating systems also use slightly more memory than a 32 bit one on teh account that registers use 2 times as much memory. While this may be slight for some applications it may be big to others. So then at least go 6GB, better yet 16GB.

NOTE: it does not just help to get a 64bit system also the program needs to be compiled for the use of 64bit memory. So you would also need to upgrade your maya!

The theoretical memory limit for a 64 bit system is 2^64 is 18446744073709551616 (thousands of exabytes) and that's quite much more. So no we are not moving imto 64 bit systems and multithreaded applications because we want to. Rather we are doing it because we have NO CHOICE


PS: as a general rule you can not expect to solve your problems by just pumping more power behind your solution. It just don't work, A exponential fuction spirals out fo control so fast that brute forcing helps not.

If you want to disconnect your lap top, you will need MR or Maya lics on your rack. MR Standalone can do command line renders without using a que. To split the still frame into sections using commands, you can add those command flags by hand, or you can use a que like Render Pal to make the splitting math easier. Also, our MR standalone logs say that more than one cpu is rendering a single frame, sort of like frame splitting...however, frame splitting should lower the memory needs of those boxes...correct Joojaa?

-To render MR jobs using our rack, we found 3 general options...

1 install satellite (free)...down side, cant pull your laptop off the rack after launching the render, it needs to stay connected....and sat only uses 8 additional remote CPUs with Maya unlimited, and only 2 with complete. Also, Joojaa...do you know if it true that some MR render process are not supported by sat, like FG???. Up side, no need to export .mi files...and thats good because .mi files can get very large...into the many gigs sometimes. And you can lauch renders without a command line, simply batch render from within Maya. You can not disconnect your laptop if thats were you launch your render.

2 Buy MR standalone lic for each box ~ $1,000.00 per box plus $200.00 maintenance a yr per box. Downside is the need to translate your .mb and .ma files to .mi. Also need to launch renders with a command line or render que. You can disconnect your laptop.

3 Buy a Maya lic for 4 boxes, or use your workstations that already have a Maya lic as rack boxes, (limit 4 local cpus) and use a render que like smedge to launch MayaMR (not the same as standalone) using .ma or .mb files. No command line needed, no .mi files needed. You can disconnect your laptop.

What a lot of good information, my thanks to gmask, joojaa, and garywelch.

It's good to know that all my 32 bit work is not down the drain.

A couple of mentions were made about rendering in layers or splitting-up the render to avoid the choking problem. I haven't figured out what has been causing the incrediblly long renders (24+ HOURS). My scenes use FG (no GI, occassionally Caustics) and fur. There are several different surfaces with miss_fast_skin_maya and several kinds of fur (sparse, like arm hair). My light maps are the same res as my render res (not 2x bigger - I didn't see a difference and it made the render times more insane). I did try the split method idea, but the there was always a bit of a mismatch between each of the tiles (even with rebuild FG off). I did see a mention on some board about reducing the segments of the fur greatly reducing render time, but my segments are at the default value or just a bit higher. I do take the advise that more memory is not the cure-all very seriously, I just haven't figured out how to render smarter yet. So I'll just have to use the stupid but strong method for now.

So what I'm taking away from your posts is:

I will need to buy a 64 bit license of Maya (running a 32 bit app on a 64 bit OS won't do any good).

I'll run Maya not mr on the master renderer since I don't want to deal with huge .mi files.

If I want to split-up the render between a master a slaves I'll need smedge. I assume that smedge does something more sophisticated than my tiling efforts so I won't end up with mismatching tiles.

Thanks again, guys,

Matt

This can be a boon for your workflow as you can split up the generation to several files wich can bring your overheads down. BUt teht would require you to have a full time render pipe designer. (but hey it CAN be cheaper than getting more mechines i mean if he can reduce 24H to 18H you win big time)

You know what they say about assumptions? No Smedge does not do anything special. What you will have to do is create tiles that actually overlap so you can fade out the edges and thus blend them.

From what you have described.. probably the only thing that will speed is up a faster computer. There are probably more optimizations you could do.. If there is alot of geometry then being able to render some of it seperately will help. It kind of hard to give specific suggestions without having seen the image you're working on.

If you did go 64bit it probably won't make things any faster but it will let you render larger or with more data. Supposedly 64 bit can even be a little slower when it comes to memory intensive operatiosn because there is more overhead to manage the additional memory.

Hey something cliked in my brain here! Check 2 things. Get something like process explorer (it mekas seeing this esier in the future)

http://technet.microsoft.com/en-us/sysinte...s/bb896653.aspx


When you render does your harddrive go wild? If so you may be gone paging this kills perfomance. you should see a lot of disk activity but almost no processing. If so reduce the bsp size bot/map/dds/tex (whatever depending on your renderer) your textures. This could help if the over allocation is slight.


if its this then going 64 bit helps BIGTIME.

Also chek if you have astounding kernel rate computations might indicate a driver failure.

Joojaa and Gmask,

Thanks again for your help.

Gmask, as far as tiling goes, it seems that you're saying that this ever-so-slight mismatch and the need to blend the edges is a "feature" (of Maya, of mr?) and is not something I did wrong. If so, I'm kind of disappointed in the program. I know that the rebuild FG on/off/freeze was probably put in to maintain continuity across frames of animation, but I thought it would also provide FG continuity WITHIN a frame as well.

Joojaa, my laptop really bogs down when I render. I guess I'd have to start process explorer before I start a render.

There isn't a lot of geometry in the 2400 x 3000 pixel tests I've been running. About 30 slightly bulged nurbs planes, and it takes hours.

I'm starting a render now and leaving town (no cause and effect). I'll post again on Monday.

Thanks again,
Matt

I'm not saying it's a feature, but there are other instances where you may need to overlap tiling such as if you use glow. But yes it is not because you did anything wrong as far as I know.


>>>If so, I'm kind of disappointed in the program. I know that the rebuild FG on/off/freeze was probably put in to maintain continuity across frames of animation, but I thought it would also provide FG continuity WITHIN a frame as well.

Well I can't tell you if this would happen in other programs or not. Personally I rarely use FG because it is slow, it used to jitter really badly on animation and for the most part I can get similar effects in other ways that are more reliable.

If there was a program that was perfect we'd all be using it right?