Pages: [1] 2 
|
 |
|
|
Author
|
Topic: Network rendering problemL No image output with exrTrader 1.1a and BNR4.03 (Read 2710 times)
|
|
Mike Popovich
|
Installed the latest exrTrader with BNR4.03 running LW 9.3. A test scene was run through the pipeline, but no image files are written to the output directory. The LWSN log shows an entry for writing the image file, but it also shows OpenEXRSettings master handler failing. I removed the master plugin and it stills fails to write. When running rendering the scene locally, exrTrader successfully writes the images out.
LightWave x86 ScreamerNet Module (Build 1269)CPU number: 625
sendack: Initializing
x86
Current directory is now "V:\Jobs".
Clearing scene
Loading settings
Pre-processing scene
Loading plug-in
Plug-in class "MasterHandler" name ".SceneEditorStandardBanks" slot 1
Plug-in loaded
Loading plug-in
Plug-in class "MasterHandler" name "OpenEXRSettings" slot 2
Plug-in failed!
Loading "GMC_House/Objects/Work/MP/h03_houseOuterShell_V005.lwo"
Loading "GMC_House/Objects/Work/MP/h03_houseOuterShell_V005.lwo"
.
.
.
.
.
Image Reconstruction : 91%.
Image Reconstruction : 93%.
Image Reconstruction : 95%.
Image Reconstruction : 97%.
Image Reconstruction : 99%.
Writing RGB image to V:\Frames\GMC_House\h03\+work\mcpRenderTest\mcpRenderTest.0001.exr.
Frame completed.
Last Frame Rendered: 1.
Rendering Time: 3.5 seconds.
Freeing segment buffers.
Freeing frame buffers.
LightWave x86 ScreamerNet Module (Build 1269)CPU number: 625
I'm going to try run a LWSN test using a command line batch file to simulate the same command BNR4.03 executes to prove the problem is with BNR4.03. I also see the same problem with previous version of exrTrader and BNR.
|
|
|
|
|
Logged
|
|
|
|
|
lightwolf
|
Hi Mike,
thanks for the detailed log. The master handler shouldn't fail... nonetheless... images ought to be written even if it fails (at it does is provide the settings for the EXR file - if it isn't present, the files are written using the defaults).
The only things that strikes me as being off is that you're writing to a directory that is outside of the content structure, but that should be no problem either, especially when using the normal OpenEXR saver (which doesn't do any file name manipluation at all).
I'll try to reproduce the issue here using a similar path set-up as yours.
Cheers,
Mike
|
|
|
|
|
Logged
|
Optimism is an occupational hazard of programming: feedback is the treatment. (Kent Beck)
- skype: lupus_lux -
|
|
|
|
Phil Stopford
|
Interestingly, I'm seeing nodes completely wedge with the dummy saver applied as well as the image filter. Just after the 'rendering frame' line is shown, all CPUs spin at 100% and then nothing more happens. I've had CPUs churning for a combined total of days of render time before I caught this :/
|
|
|
|
|
Logged
|
It could be dangerous. Bring the toy fish.
|
|
|
|
lightwolf
|
Interestingly, I'm seeing nodes completely wedge with the dummy saver applied as well as the image filter. Just after the 'rendering frame' line is shown, all CPUs spin at 100% and then nothing more happens. I've had CPUs churning for a combined total of days of render time before I caught this :/
Which render controller are you using? I'll be having a look at that later on today, and hopefully I can track it down. A problem with the dummy saver is weird, as it doesn't really do anything... Cheers, Mike |
|
|
|
|
Logged
|
Optimism is an occupational hazard of programming: feedback is the treatment. (Kent Beck)
- skype: lupus_lux -
|
|
|
|
Phil Stopford
|
ScreamerNet Controller 4.09c
He recently added support for your dummy saver. I'm slightly confused though because it doesn't even get as far as trying to save an image.
|
|
|
|
|
Logged
|
It could be dangerous. Bring the toy fish.
|
|
|
|
lightwolf
|
ScreamerNet Controller 4.09c
He recently added support for your dummy saver. I'm slightly confused though because it doesn't even get as far as trying to save an image.
Does your scene have the master handler applied as well? Does it work if you use another saver? Cheers, Mike |
|
|
|
|
Logged
|
Optimism is an occupational hazard of programming: feedback is the treatment. (Kent Beck)
- skype: lupus_lux -
|
|
|
|
Phil Stopford
|
If I use any other saver other than the dummy saver, the same scene works just fine (and is rendering out right now). It had me very puzzled to work out what was going on - especially since no image saving was taking place
|
|
|
|
|
Logged
|
It could be dangerous. Bring the toy fish.
|
|
|
|
lightwolf
|
If I use any other saver other than the dummy saver, the same scene works just fine (and is rendering out right now). It had me very puzzled to work out what was going on - especially since no image saving was taking place
Allright, that is extremely strange... is that using the latest release version of LW? Cheers, Mike |
|
|
|
|
Logged
|
Optimism is an occupational hazard of programming: feedback is the treatment. (Kent Beck)
- skype: lupus_lux -
|
|
|
|
|
|
lightwolf
|
Installed the latest exrTrader with BNR4.03 running LW 9.3. A test scene was run through the pipeline, but no image files are written to the output directory. The LWSN log shows an entry for writing the image file, but it also shows OpenEXRSettings master handler failing.
Hi Mike, I had a look here and it works with 9.3.1 as expected... Now, the question is... can your nodes actually access the plugin? Maybe you could check the plugin config file used by the nodes to see if it contains exrTrader, and check if the nodes can access the plugin as well. Cheers, Mike |
|
|
|
|
Logged
|
Optimism is an occupational hazard of programming: feedback is the treatment. (Kent Beck)
- skype: lupus_lux -
|
|
|
|
Mike Popovich
|
BNR had a bug that caused this problem. Paul Lord sent me a patch and it fixed this problem on our pipeline. I assume it will be incorporated in the next release. Move along, there is nothing to see here.  Thanks, Mike |
|
|
|
|
Logged
|
|
|
|
|
lightwolf
|
Move along, there is nothing to see here.  *phew*  You're welcome  Cheers, Mike |
|
|
|
|
Logged
|
Optimism is an occupational hazard of programming: feedback is the treatment. (Kent Beck)
- skype: lupus_lux -
|
|
|
|
Phil Stopford
|
My problems still continue and I'm somewhat at a loss to explain them. One of the issues is a problem in exrTrader
- SNC4 loops the same frame over and over again because exrTrader defaults to writing out frmXXX files, but LW seems to (for me) output frmXXXX files. The dummy saver and the image filter saver don't agree, so SNC believes the node has crashed and requests the same frame to render. I'm not sure if this is an SDK limitation - Mike?
My more serious issue is that the Mac Mini, serving as a general workhorse (file server, LWSN node) stops responding to any fileshare activity after around 3-6 hours. It's wired into the router and still responds to VNC requests, but other than that it's dead - the machine actually won't reboot either in these situations, needing a hard power off. Commonly, the last line to be seen on the terminal is exrTrader throwing an exception because the file data cannot be written (to a local drive!). The MBP LWSN render naturally wedges at the same point because the location is no longer responding over the network. Argh.
I'm scratching my head over this whole thing. I thought a wired connection would resolve this, but it seems to be a more fundamental problem. I'm going to try a lengthy render without exrTrader just in case. I'll also try mode 3 LWSN renders on both machines to see if it is provoked that way. I also need to see if the firewire interface on the main storage drive is playing with me - moving the drive over to a USB port may help....I need to check. I'm halfway wondering if there's something being provoked by the drive going to sleep and not responding in a timely manner (the drive does this itself - OS X's energy savings on the Mac Mini are all switched off, except for display sleep).
*mutter*
I'm not sure if this is an OS X oddity either.
|
|
|
|
|
Logged
|
It could be dangerous. Bring the toy fish.
|
|
|
|
lightwolf
|
My problems still continue and I'm somewhat at a loss to explain them. One of the issues is a problem in exrTrader
- SNC4 loops the same frame over and over again because exrTrader defaults to writing out frmXXX files, but LW seems to (for me) output frmXXXX files. The dummy saver and the image filter saver don't agree, so SNC believes the node has crashed and requests the same frame to render. I'm not sure if this is an SDK limitation - Mike?
It is, the number of digits and the frame format needs to be set manually in the exrTrader GUI to match the output settings of LW. exrTrader can only read out the path and base file name, but not the format used by LW to build the final file name. I'm not sure if this is an OS X oddity either.
That could well be. USB should be fine, OSX on intel CPUs handles those just as quickly now as FW drives (if you run Leopard). One thing that might help is getting a cheap SOHO NAS... you can get cases for two 3.5" drives (that allows for a mirror) for around 200€, plunk in two 500GB drives and you're at less that 400€. Not ideal but maybe more reliable (plus they use a lot less energy if they run 24/7). Cheers, Mike |
|
|
|
« Last Edit: April 03, 2008, 10:52:02 AM by lightwolf »
|
Logged
|
Optimism is an occupational hazard of programming: feedback is the treatment. (Kent Beck)
- skype: lupus_lux -
|
|
|
|
Phil Stopford
|
USB seems to be performing a lot better. The Macs were still running fine this morning. Strange how the Linux nodes have never caused this much trouble  |
|
|
|
|
Logged
|
It could be dangerous. Bring the toy fish.
|
|
|
|
Pages: [1] 2 
|
|
|
 |
