PDA

View Full Version : ScreamerNet Enhancements . . .



Matt
02-05-2004, 05:40 AM
I think ScreamerNet needs an overhaul myself, however, if we're going to keep the same one for the time being here's some simple requests that shouldn't be too difficult to do:

1) Change the node feeback text to help newcomers to LightWave:

Instead of "Can't Open Job File" (which sounds like an error)

Say something like "Waiting for job command file, please initialise ScreamerNet ..."


Instead of "LightWave Command: init."

Say something like "ScreamerNet Initialised Successfully"


Instead of "LightWave Command: wait."

Say something like "Render node X ready, waiting for scene files from master controller ..." (X=node number)


2) When ScreamerNet is running, please allow us to scroll the list of CPUs, it gives the impression it's crashed because it doesn't work.


3) Don't calculate the % done by how many frames have been loaded, e.g. if you had a scene with 30 frames and you had one hundred CPUs, all 30 frames would be loaded and the status says it 100%, even if it's just started!!! Confusing! It _should_ be based on frames rendered!

There are more but that's all I can think of right now!

Cheers
Matt

Panikos
02-05-2004, 06:17 AM
The concept of SN rendering works very well, with BNR in mind as well as some other SN external controllers.

I dont think that this protocol needs any change.

Of course the native LWSN controller needs a revision, even though there is no gap to fill. External controllers are rather affordable and work very well.

Matt
02-05-2004, 07:33 AM
never said anything about changing _how_ it works underneath, passing commands via files is quite clever actually, I just think it needs an overhaul to make it a LOT more friendly to use, esp. for new users.

how many posts do we see on the forum about setting it up!!!

yes there are third party controllers that work, I'm suggesting stuff to make the out of the box solution better.

:)

Panikos
02-05-2004, 08:38 AM
heh Matt

:cool:

My replies dont necessarily imply disagreement. Its just one more opinion, right or wrong, always with constructive intention
I prefer the NT-Discussions than the Mailing List :D

pixelinfected
02-18-2004, 08:08 AM
Screamernet must aligned to lw render engine, too often there is difference from one to other, for example :

-g2 with lw75c screamernet render black, but lw75c work fine,screamernet 75b, 75 work well.

-scene with hypervoxel some times are not linear on moving (motion done by internal algorithm of hypervoxel, not using particles).

-screamernet not give feedback to know if it work or is locked.

-screamernet not ignore some master plugin message (like spreadsheet and item picker) and give error.

- with low memory not load plugin saver and save in dds format, but with high resolution cut a part of image arbitrary.

- on critical (high demand poly and memory request) cause crash or strange lock of screamernet, but lw render fine (not every time.

what screamernet need :

- more info and communication command
- an option to have a counter to understand completation, a simple pixel evaluted counter.
- more confortable interface (we have bought butterfly, which rocks on pc and mac, but i hope someone remember its work and finish to develop stealthnet, bob hood develop a revolutionary net render system for 6.5, on 7 was missed, and with 7.5 come back, but no one tell about it, about its stability, and working. i hope comple the develop for pc, mac and linux, or simple a render node controller, like butterfly do.
- more debug info to understand what is the problem with scene.

Mylenium
02-18-2004, 08:46 AM
Well, while Screamernet works most of the time, I'd still vote for a totally new Screamernet instead of enhancing the old one. There are simply too many quirks such as plugins never working with it and some more control and feedback would certainly be of great help. Also sticking to LWSN somewhat hinders development of the LW renderer. Things such as real distributed rendering or separate chunks cannot be implemented with such an infrastructure.

Mylenium