PDA

View Full Version : Screamernet Unexpectedly Quit



squidsquidsquid
04-04-2003, 10:51 AM
Hopefully this is a quick question with a quick answer. If Screamernet works fine for most scenes, but crashes for a few, would that indicate a problem with the scene? I have different projects in different folders and am sure to change the LWSN command line to the appropriate path. It's just one set of scenes that are fairly complex that seem to crash LWSN. They render fine as "F10" renders. The moment I Screamer Render, LWSN "unexpectedly quit"s and LightWave is frozen and thinks it is still loading the scene. I then have to "force quit".

Thanks for any and all help.

roberthurt
04-04-2003, 02:59 PM
I am having a similar problem with some nodes unexpectedly quitting on a work network. On one render with 2 DP machines, both the host and remote nodes each lost one LWSN to unexpected quitting.

I've got a possible theory, but not one I'm likely to be able to test for a few days... may it be related to threaded renders? I never realized until reading another post that LWSN apparently will thread renders based on the Render Options setting, and that setting threads to "1" may result in fastest render times...

cremegg
04-04-2003, 04:05 PM
Ensure that Threads is set to 1 in the render options panel of LightWave and then quit to save the prefs. LWSN will attempt to use the specified number of Threads in the pref file and anything above 1 will cause instability as LWSN is designed for 1 CPU.

LWSN (1 Thread) will not likely be faster than 8 threads using Layout but may render a bit quicker than the same render using 1 thread and Layout as LWSN has less overheads.

When rendering an animation this may ultimately yield slightly quicker render times but LWSN uses the same render engine as Layout and it could not miraculously achieve quicker times for a single frame than Layout running with 8 threads.

roberthurt
04-04-2003, 09:54 PM
Yes, I didn't mean to imply you'd get LWSN to go faster than layout; for reference, Julian Johnson posted some interesting benchmarks for Layout/LWSN using different numbers of processes/threads in another thread. (http://vbulletin.newtek.com/showthread.php?s=&threadid=2745)

So this raises an interesting question: Cremegg, you're saying that the threads are saved in the lightwave config files, not the scenefiles? I'm now starting to think that it would be a good idea to dupe those files elsewhere and point the LWSN notes at that copy after making sure it was set to 1 thread. That way you'd never have to worry about Layout threading causing problems with LWSN.

Julian Johnson
04-05-2003, 12:36 AM
cremegg - I'm not so sure that multiple threads are a problem for LWSN. If you're using a single instance of LWSN on a single machine then it makes sense to increase threads to whatever delivers the fastest render times. In the benchmarks I did (in the link Robert posted), a single instance of LWSN running 8 threads was significantly faster than the same instance running 1 thread. The strange thing was that LWSN wasn't getting anywhere near the render speeds of Layout itself. In terms of reliability, I've always run LWSN with multiple threads (for Mode 2 and Mode 3 renders) and it's never been a problem. So, I think the benchmarks demonstrate that LWSN is designed to use threads in single instance mode.

However, as soon as you fire up two copies on the same machine the value of threading is lost immediately and you should set threads to 1.

robert - yep, cremegg hit the nail on the head: the thread setting is stored in the Preference file which makes 'managing' threads a bit trickier especially if you intend to carry on working in Layout on the host machine.

Julian

Julian Johnson
04-05-2003, 12:42 AM
One thing to check with LWSN quitting or stalling is that the scene files themselves don't have multiple spreadsheet entries (or, indeed any spreadsheet plugin entries) at the top of the file. Open in a text editor and remove them all completely. (Example of what you should be removing below). This is known to cause LWSN to stall on loading and might be responsible for some quitting.

Plugin MasterHandler 2 .SpreadsheetStandardBanks
EndPlugin
Plugin MasterHandler 3 .SpreadsheetStandardBanks
EndPlugin
Plugin MasterHandler 4 .SpreadsheetStandardBanks
EndPlugin
Plugin MasterHandler 5 .SpreadsheetStandardBanks
EndPlugin
Plugin MasterHandler 8 SpreadsheetSceneManager
{ IMP
1
{ Workspace
"Default"
ShowLockedItems 1
SupplementalRows 1 0
MultiselectSimilarTypes 1
UseLayoutLocking 0
UseLayoutTimelineLocking 0
ItemLimitMode 1
ItemSortMode 0
UseItemFilter 0
ItemFilter "" 0 5
ShowFilterControls 1
ShowBanks 1
ShowTimeline 0
BankDivider 0.40000001
{ Bank2
Class 1
PresetID 5f494e53
Column 5f494e53 0 120
Column 5f494e53 1 120
Column 5f494e53 2 65
Column 5f494e53 3 65
Column 5f494e53 4 70
}
{ Bank2
Class 1
PresetID 5f4d494b
Column 5f4d494b 0 50
Column 5f4d494b 1 120
Column 5f4d494b 2 65
Column 5f4d494b 3 50
Column 5f4d494b 4 50
Column 5f4d494b 5 50
}
TimelineDivider 150
TimelineZoom 2
TimelineRange 0.039999999 2.4000001
}
CurrentWorkspace 0
}
EndPlugin
Plugin MasterHandler 9 ProxyPick
1
0
0
4
EndPlugin
Plugin MasterHandler 10 ProxyPick
1
0
0
4
EndPlugin
Plugin MasterHandler 11 SpreadsheetSceneManager
{ IMP
1
{ Workspace
"Default"
ShowLockedItems 1
SupplementalRows 1 0
MultiselectSimilarTypes 1
UseLayoutLocking 0
UseLayoutTimelineLocking 0
ItemLimitMode 1
ItemSortMode 0
UseItemFilter 0
ItemFilter "" 0 5
ShowFilterControls 1
ShowBanks 1
ShowTimeline 0
BankDivider 0.40000001
{ Bank2
Class 1
PresetID 5f494e53
Column 5f494e53 0 120
Column 5f494e53 1 120
Column 5f494e53 2 65
Column 5f494e53 3 65
Column 5f494e53 4 70
}
{ Bank2
Class 1
PresetID 5f4d494b
Column 5f4d494b 0 50
Column 5f4d494b 1 120
Column 5f4d494b 2 65
Column 5f4d494b 3 50
Column 5f4d494b 4 50
Column 5f4d494b 5 50
}
TimelineDivider 150
TimelineZoom 2
TimelineRange 0.039999999 2.4000001
}
CurrentWorkspace 0
}
EndPlugin
Plugin MasterHandler 12 ProxyPick
1
0
0
4
EndPlugin
Plugin MasterHandler 13 ProxyPick
1
0
0
4
EndPlugin
Plugin MasterHandler 14 SpreadsheetSceneManager
{ IMP
1
{ Workspace
"Default"
ShowLockedItems 1
SupplementalRows 1 0
MultiselectSimilarTypes 1
UseLayoutLocking 0
UseLayoutTimelineLocking 0
ItemLimitMode 1
ItemSortMode 0
UseItemFilter 0
ItemFilter "" 0 5
ShowFilterControls 1
ShowBanks 1
ShowTimeline 0
BankDivider 0.40000001
{ Bank2
Class 1
PresetID 5f494e53
Column 5f494e53 0 120
Column 5f494e53 1 120
Column 5f494e53 2 65
Column 5f494e53 3 65
Column 5f494e53 4 70
}
{ Bank2
Class 1
PresetID 5f4d494b
Column 5f4d494b 0 50
Column 5f4d494b 1 120
Column 5f4d494b 2 65
Column 5f4d494b 3 50
Column 5f4d494b 4 50
Column 5f4d494b 5 50
}
TimelineDivider 150
TimelineZoom 2
TimelineRange 0.039999999 2.4000001
}
CurrentWorkspace 0
}
EndPlugin

cremegg
04-05-2003, 04:03 AM
Well not so long ago Julian I stumbled accross the fact that LWSN could use threads and I acheived some impressive benchmarks from it. However only a few days after testing 2 - 8 threads everything suddenly became unstable and the only way I can now get LWSN to render succesfully is with 1 or 2 Threads although I shy away from 2 Threads for the fact of stability. Me and a colleague have been documenting render crashes with Layout and these seem related to threads. The crash logs from LWSN are also identical. This is running 1 instance of LWSN.

Julian Johnson
04-05-2003, 06:12 AM
Hi cremegg - ouch, that sounds bad. For the past few years I haven't been paying any attention to how many threads LWSN is using. It's just picked up whatever I have Layout set to (4-8), and hasn't crashed with any regularity. I guess the rule of thumb should be: if you're using a single instance of LWSN then start out with the same optimal number of threads as you're using in Layout and then, if you experience crashing, reduce the thread count if you're getting instability? I'd hate to think of how much longer projects would take if I always had to run LWSN in singled threaded mode. It's a price worth paying for stability, I guess.

Good luck with documenting and recording the Layout/LWSN crashes related to threading. It will be interesting to hear if you narrow down the problem. A long time ago, mapped image sequences and multiple threads didn't work well together - maybe there are some other scene-specific factors at play?

Julian

cremegg
04-05-2003, 06:39 AM
I have sent a number of crash reports to Newtek very recently documenting recuring Layout crashes (Apologies if this is causing delay to 7.5b ;)) in relation to rendering although I haven't included LWSN as I wasn't sure Newtek would support multiple threads for LWSN. It is possible the issue is related to the Carbon API and pthreads although that is just our first guess and we may be way of the mark.

I repeated a few tests this morning with LWSN and the same scene file I have been using to test LWSN with various thread settings and again I can't get above 2 threads without LWSN crashing shortly after beginning to render the first pass.

I cannot recall exactly but I believe the successfull thread tests (4 and 8) where achieved after a fresh install of LW 7.5 (Due to the fiasco of LW 7.5b). Although why everything appeared to break after a few days I cannot even begin to guess.

It could be a Layout Preference setting, a minor error written to the scene file or possibly the exact way the LWSN cmdline is written.

LW Sequencer and Launch Mode 3 seem to write the command line with varying degrees of complexity. LW Sequencer and Layout set to 8 threads caused LWSN to lock up after Optimization of Models/Layers. Launch Mode 3 caused LWSN to crash shortly after starting the first pass using 4 threads.

I may look further into this today and tomorrow and see if I can pin down any specifics as its definately something I would like to be able to achieve with consistency.

ironlips
04-06-2003, 03:40 PM
Julian your suggestion to remove any spreadsheet entries at the beginning of file seems to be the correct solution for me. This problem has been troubling me for some time and I tried setting threads to 1, which made no difference as I expected. Opened lws file with text editor and saw those nasty multiple spreadsheet entries... deleted them and set a render, IT WORKED.

I recently had an a problem with files I sent to a render farm. They could not render 1 of 5 scenes and we couldn't work out why, I'm gonna give this method a try and see if it works there. But we were guessing there was some mac to pc issue.

Do we know why these spreadsheet entries pop up occasionally on some scenes and not on others?

Julian thanks for your help :)


Tony Lee

cremegg
04-08-2003, 11:01 AM
Well my scene file doesn't contain any spreadsheet entries but I have successfully tested a number of the benchmark scenes using LWSN and 4 or 8 threads soooo....

I assume the problem is scene or object specific. Haven't managed to narrow it down any more. The scene uses dence subpatching and a few displacement maps....

:rolleyes:

Julian Johnson
04-09-2003, 04:31 AM
Hi Tony - I hadn't really looked at how the spreadsheet entries get in there. I assumed they only turned up after you'd opened spreadsheet and then saved the scene but I'm not sure if a) they multiply every time you save the scene or b) multiply every time you open spreadsheet. I really like spreadsheet so I've just got a routine going where I always strip out the entries before sending to LWSN - sometimes there are 20-30 entries...

Julian

Julian Johnson
04-09-2003, 04:36 AM
Hi cremegg - well, in a way that sounds promising :-). If you want to send me a pared down scene that still bombs LWSN, I'd be happy to have a look, too. My hunch would say displacement maps....but we're getting into mystical territory. Would be interesting to try with the maps removed. Are the maps image sequences?

Julian

cremegg
04-09-2003, 05:30 AM
Well Julian this just gets more bizzarre everytime I alter something. I removed both displacement maps, LWSN seemed to stall during or after optimiziation no matter the thread setting :rolleyes: . I then scaled down the subpatch level for rendering to 3, this eleviated the stalling after optimization but LWSN crashed again on pass 5/11 which is where it starts to render geometry. I'm at a loss. I suppose it could be a problem with subpatch objects or resolution. It doesn't seem related to Segment Memory :rolleyes: .

mlinde
04-09-2003, 09:45 AM
I recently had trouble like this, and it's because I had parts of plugins installed and not used. I had been playing with G2 in a test scene, and it was on an object in my main scene. When I removed the G2 plugins from the object surfaces, my scene rendered without crashes in LWSN. It had previously rendered without crashes in Layout, probably because Layout could access the master plugins all the time.

Why not check that you have removed any unused plugins, or that you have added any master or scene plug-ins for surface plugs you are using?

cremegg
04-09-2003, 11:09 AM
I don't really follow you mlinde.

I resaved the scene which has been giving me grief and set the camera resolution multiplier to 25%, Threads to 8 and used mlinde's Launch Mode 3 LScript to write my cmdline. It rendered fine. I then used the same scene but set the resolution multiplier to 50%. This crashed the first time but I retested succesfully. I then tried a resolution multiplier of 100%, basically the same settings from my original scene file, and it rendered fine. This baffled me slightly so I thought I'd try again with a 100% resolution multiplier although this time I used LW Sequencer to write the cmdline but LWSN crashed. I tried writing the cmdline with Launch Mode 3 and setting the resolution multiplier to 25% but LWSN crashed again.

Definately an 0dd thing.

mlinde
04-09-2003, 03:23 PM
I was adding to the comments about things that crash scenes in LWSN, whether Mode 2 or 3. The scene in question rendered fine via F10, but would crash in either LWSN mode. The problem was partial application of plug-ins with multiple instances. I was offering additional information about scene crash issues with LWSN. Not specifically replying to your resolution multiplier stuff...