[casey]

I am trying to get distributed cooperative rendering working, and although it does seem to run and all machines involved do end with "Success", the image that is produced seems to be the same as if a single machine had done the render.

Here is the image produced by a single machine that runs to SL10:
http://funkytroll.com/temp/single_machine.bmp

Here is the image produced by five machines that all run to SL10:
http://funkytroll.com/temp/multi_machine.bmp

Although their noise patterns are different, it seems clear that they are both the same quality, whereas 5x SL10 should at least be somewhat better than 1x SL10.

It is obvious from the amount of time taken that all five machines have, in fact, computed an SL10 image, so something is not working properly in the merge step. Do you have to do something special to get the merge step to work? It seems like I am getting the result of just a single farm machine's render, instead of the combination of all five. I'm specifying the option

Code: Select all

-mxi:"w:\temp\multi_machine.mxi"

where w is a drive mapped on all the machines to point to a single server directory. It is the same directory that houses the .mxs. The multi_machine.mxi is produced, but as shown, it does not appear to actually be the composite, but rather perhaps just the result of a single machine's rendering, discarding the results of the other four.

- Casey

[bugyboo]

i think you have to collect cooperative.mxi from Maxwell instalation directory and merg them togather.. you will get a less noisy image.

[casey]

i think you have to collect cooperative.mxi from Maxwell instalation directory and merg them togather.. you will get a less noisy image.

So what exactly is the "sending MXI"/"merging MXI" stuff that the mxcl network display shows when the render is complete? Is that just a nonsense message? Because it certainly sounds like it's doing a merge there...

On a related note, I don't suppose you can run an MXI merge from the command line?

- Casey

[insomnia3d]

i have the same issue,
but when the nodes finish they state that they are merging the MXI's.....
I am breaking my head with this one.

[bugyboo]

well, i don't know what sending / merging do !

and you can't merge MXI's from command line either..

[b-kandor]

um, this is an important question - especially in about 3.5 hours So does anyone know what is going on with these merging questions?

Thanks,

Kandor

[insomnia3d]

beats me, and i really need to figure it ou...

[bugyboo]

beats me, and i really need to figure it ou...

yeah somtime i feel that some of maxwell option left mystery to the users. why can't it be explaind more and stright forward

[Peter_K]

I´ve done some investigation, so I hope this will shed some light to the subject (and that Im correct in my assumptions).

First of all. The .mxi file specified in the mxcl viewer should point to a place where every rendernode has access (point it to the same place as your .mxs files is resident)

Now, when you start a cooperative render, each node takes the .mxs file at copies it locally to its C drive (maxwell root) and calls it cooperative.mxs. Once one of the rendernodes is finished it will save down a .mxi file called cooperative.mxi in the same place (maxwell root).

Once all nodes are finished, the merge begins. NL had explained it in the manual but I'll try to explain it aswell. Instead of sending mxi files back and forth across the network to a single rendernode (that will certainly crash when trying to merge twenty 260mb .mxi files together) they create pairs. So if you have let say 20 rendernodes. Rendernode 1-10 will send their cooperative.mxi to node 11-20. So node 11 will get the .mxi file from node 1, and take its own cooperative.mxi file and the received one, and save down a new .mxi called merge.mxi (also resident in the maxwell root). Node 12 will get node 2s .mxi file and so on. Now we end up with 10 merged .mxi files instead of twenty. Now 5 nodes starts merging those 10 .mxi files. then its merges those five into three. Those three into two, and atlast into one single merge file that is being saved down to the directory you specified in the mxcl viewer.

I hope my explanation is correct.

/Regards Peter K

[bugyboo]

thanx Peter for this good explanation.
So, where exactly the last marged mxs ended up ? in my situation all my node doesn't share exact same folder or they not sharing. i copy all my files on them at same path and start cooperative. is that mean that mxcl will merg them togather ?

[insomnia3d]

mine are sharing the same network location and its only three machines for now, but i still end up with a low SL image.

[bugyboo]

hmmm,, i see

i need to test more,,

[insomnia3d]

that can't be, cause you have multiple sample sources...

[bugyboo]

the only thing i can see is that when using 10 cpus coop the resulting mxi ( the mxi used as destination in the command line arguments ) is at same or even worse quality than when rendered on single node....hmmm

here is my early try for cooperative rendering only i do the merging manully..

http://www.maxwellrender.com/forum/view ... highlight=

there is a diffrent! but the Q is the merging done automatic?

[casey]

Once all nodes are finished, the merge begins. NL had explained it in the manual but I'll try to explain it aswell. Instead of sending mxi files back and forth across the network to a single rendernode (that will certainly crash when trying to merge twenty 260mb .mxi files together) they create pairs. So if you have let say 20 rendernodes. Rendernode 1-10 will send their cooperative.mxi to node 11-20. So node 11 will get the .mxi file from node 1, and take its own cooperative.mxi file and the received one, and save down a new .mxi called merge.mxi (also resident in the maxwell root). Node 12 will get node 2s .mxi file and so on. Now we end up with 10 merged .mxi files instead of twenty. Now 5 nodes starts merging those 10 .mxi files. then its merges those five into three. Those three into two, and atlast into one single merge file that is being saved down to the directory you specified in the mxcl viewer.

I agree that this is the process that should be occurring, and from the status indicators on the network monitor it seems like it is, but when I go to look at the actual output produced, it is clear that all I'm getting is the result from a single render node. Like, as if there was a bug or something where the last person who's supposed to perform the final merge accidentally just copies his result to the destination location instead of actually merging.

I am doing everything as correctly as I can determine from reading the forums. Everything is on mapped drives where all farm machines can read and write, the cooperative.* files are being produced on each farm machine, and the final destination file does get written. It's just clearly not the result of the merge.

- Casey