View Full Version : Screamer3

10-23-2003, 10:43 AM
it would be great if lightwave 8 could come up with a GOOD network
rendering program.
I know everybody talk about this problem, but it seems they are not really
working on that.
I think this issue is stoping a lot of company from choosing LW to render
large images or animations.

another detail, when you hit F9 to render, it would be cool that while it's rendering, you could still work in lightwave, having the image rendering in the background..

what do you guys think?

Zafar Iqbal
10-23-2003, 03:04 PM
Im with you!

I would also like to see a feature where F9 would render the active viewport (where the mouse is) - if outside any viewports, then just usual camera rendering.

10-24-2003, 01:54 AM

Originally posted by Zafar Iqbal
I would also like to see a feature where F9 would render the active viewport (where the mouse is) - if outside any viewports, then just usual camera rendering. What about rendering a floating view-port until we work using the "background" ones? ;)


10-24-2003, 02:56 AM
these are really old now, but this was an idea I had a while ago . . .


10-25-2003, 11:20 AM
I was just about to begin a rant about the frustration the current ScreamerNet creates myself.

I wont. ;)

Instead I shall offer some constructive suggestions.

There are some very simple concepts which could improvethings dramatically. Whether they are simple to impliment I don't know.

1 - Being able to add or remove Nodes on the fly even while a batch is rendering would be a great start, as would being able to add jobs. At the moment we either have to wait until the current batch of renders are finished or cancel the jobs to add to it in any way.

What would be even better would be if you could see all the nodes available, and selectively assign nodes to jobs.
What a cool idea.

You could even have a setting which lets ScreamerNet pick up Nodes as they become available. That would make my day. :)

2 - Some basic Interactivity You can't even scroll down the lists while a render is taking place! Why would you want to? Well while managing a render, it's often good to be able to see which node is rendering which frame.

3 - Control Being able to start and stop render nodes remotely from the host machine. And being able to view the status of each node, ie active, or inactive.

4 - Notification At present the only notification that I get when something is going wrong is when screamernet hangs for an unusuably long period of time, I find force quiting (with considerable force) to be the only option in most cases.

Avoid the crash, is it really necessary? tell us what's causing the problem's without crashing so we can fix it. Please.

Actually all of these issues are about having control over the process, which the current ScreamerNet does not provide.

[B] Another oddity is the way ScreamerNet seems to distribute frames. It appears that it does so in batches, Batch 01 goes out assigning a frame to each of the Nodes, which then go about rendering, but it seems that the next load of frames, Batch 02, wont be assigned until the first is completed. Bearable if all your CPU's are similarly specked, but what if you wont to make use of the other, lower speced machines, lying around the studio or office. After all every frame counts.
I still can't confirm whether this is true or not, we're quite convinced that there's a certain random factor somewhere in screamernet's rather eccentric code.

It may have been cutting edge once, slicing through rendering in smooth gillette like strokes, but it's just a big mallet now, more likely to drive a reasonable sized hole through your patience.

I'll stop for now. Need some coffee to keep me awake while I "render watch".

Hope to hear some good news on this front soon.

10-29-2003, 07:14 PM
these are not the real problem of screamernet, if you work with lightnet you can have all of that and more.

the real problem of screamernet are that :
- is not sincronized with lw engine, and often have bug that change significally the render which you see on test did with lw
- often go out of memory and not save the frame (if you work at high resolution, and you have only of 3 gb of ram....)
-it cannot use virtual memory during buffering
-it haven't a good progress indicator, to understand if it's lock, or work during complex operation
- it's not documented on sdk to be controlled be a complex external software
- it's not complete compatible in mixed environment (pc mac)
- cannot be paused during rendering
- cannot save render progressive in disk instead of memory, to optimize a very big rendering.
- it's difficult to setup (i setup it at blind eyes, but it's not user friendly)
- it's old and arcaic method, be more mordern!
- cannot manage correctly scene with master plugin which interact with opengl call, like slider, item shape etc, and give error
- have a lot of bug!!!!

if you use heavly it with complex scene you can see a lot of error olso on big computers (we have a lan with supermicroserver, os X server, 3dbox render engine, dual g4 macs, but screamenet are not a perfect solution in every times, often cause trouble, especially with complex raytracing rendering).