[neil hayes]

I'm seeing some unusal 'bands' of noise when using Coop rendering:

Image from coop MXI loaded in to mxcl


Here's the procedure I used:

- Started Render (mxcl), Manager and Server on host PC.
- Started Server on second PC.
- Added job using Automatic Coop option with "StandardMatTest 06-29-SpeedOpt.mxs" (changed target SL to 11)

Notes:

- Host PC WinXP (32bit), Server PC Win Vista (32bit)

- 'Success' indicated for both PC's

- Non-coop Network Render for the same scene works very well (and is easy to use)

- Repeated the test twice and got the same results.

- I saved out the image, but the noise is still there, implying is not a problem with displaying the MXI image in mxcl

These were my first tests using Coop and I will run another test with a different scene. Have you seen this before?

-neil

[tom]

This could happen when there's loss of signal during the data transfer on the network. Such loss could be due to something blocking or delaying the data flow. Do you encounter the same issue while rendering in coop and displaying the coop result? Also what happens when you display each node separately when rendering?

[neil hayes]

Update: Here's the result of another simple test.

Note. I used 'Display' for the individual nodes during rendering and both showed clear images. I also used Display to preview the coop MXI and that looked clean also. This noise was only apparent after the completed MXI i.e. after auto merging of MXI's at the end.

[neil hayes]

hi tom,

"Do you encounter the same issue while rendering in coop and displaying the coop result?"

- For the first test the noise was apparent in Coop preview
- For the second test the Coop preview looked clean
(note, only one preview used during eash test)

"Also what happens when you display each node separately when rendering?"

- did this once during the second test and both images looked clean.

-neil

[neil hayes]

Repeated the second test again.

This time I checked the image for each node at every update and they were always clean.

The noise was present in the coop preview.

The final render was clean this time.

-neil

[tom]

Are you using any resident real-time antivirus/anitspyware utility monitoring the created files all the time?

[neil hayes]

Are you using any resident real-time antivirus/anitspyware utility monitoring the created files all the time?

hi tom,

I was thinking the same thing. I will run a test with ZA disabled. Athough I must point out that I have another node based renderer that runs without issue with my current setup.

I really like the imporved Network system... if I can just get this issue sorted, then I'll be 'flying'.

Here's another strange result. I ran my simple test scene again and the Server Node showed this image (note. image rendered fine on the host)... certainly suggests that data is being corrupted:

[tom]

I've really seen this with one of my nodes last year and the problem was bad RAM (hardware-wise). I quickly ran a RAM-test and saw that it was unable to retain the data healthy. Then I replaced the RAM and problem is solved. It's highly possible this node could be causing the coop problem you're having, try among others excluding this as well. About ZA and similar software, well they could be working with other network applications but maybe they are using other protocols and ports, that's why. But from your last image I highly started to suspect from that node specifically.

[neil hayes]

Hi tom,

RAM seems fine, also checked resource useage for the Vista machine and thats fine also. The corrupted geometry seems like a one-off as it has not occurred again (after many tests). I also switched to use the Vista PC as the render manager, just to rule that out also.

I've just sent the same scene (red ball) as individual jobs to both computers at the same time and checked their MXI's and they seem OK. This suggests to me that the problem is occuring during the MXI merge phase.

Since no one else seems to have this problem feel free to move this post to General Discussion.... I'm going to try a manual coop next and will post the results later.

cheers,

-neil

[tom]

So, that corruption is surely similar to same loss of data issue when merging. Makes sense...

No, I think your post is very welcome under this section because maybe there's something possible to fix on our end. Even if nobody else is having this problem, maybe that could be fixed with additional coding. In our tests, transfers ranked 98/100 successful and the rest of 2 didn't happen for the second time so we decided to call it robust enough. This shows maybe we still can make it better.

Thanks!