Wine 2001.11.08, FreeBSD 4.{2,4}, Lightwave 5.6 Screamernet Node

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Sorry for the limited detail here.  To make matters worse, I don't have
access to the machines in question any more.  But perhaps someone would
be able to give me some pointers to useful avenues to pursue.

I'm trying to use Wine on FreeBSD (versions 4.2 and 4.4), to act as a
Lightwave 5.6 render node, using Lightwave's ScreamerNet software.  The
software is for NT 4.0.

This software works by having a central "controller".  The controller
share's it's C: drive to everyone else on the network[1].  The clients
(nodes), map this share to a drive letter (e.g., Z:, and it's not enough
to use UNC paths, you have to do the mapping).  Then they run a program
from the Z: drive, giving it a couple of parameters that point back to
the share.

A typical invocation on the first node would be (after sharing C: on the
controller as c_drive)

    C:\> net use z: \\controller\c_drive
    C:\> z:
    Z:\> newtek\programs\lwsn.exe -2 z:\newtek\programs\job1 \
           z:\newtek\programs\ack1

The second node uses ...\job2 and ...\ack2, and so on, for each
additional node.  The controller and the nodes co-ordinate with one
another by reading and writing to these files.

lwsn.exe is an NT console application, it doesn't use the GUI.  Notice
that none of the Lightwave software is stored on the render node -- it's
all stored on the server.

After running lwsn.exe on each node, you then kick off the rendering
on the controller.  The controller hands frames out to the nodes, and
reports on their progress (i.e., which frame each node is on, and so
forth).

I have installed Wine on FreeBSD using the package for Wine 2001.11.08.
I've set this up so /usr/local/wine/drive_c is the C: drive for Windows
applications, and created a TEMP and WINNT directory in there.  I've
populated the WINNT directory with a complete clone of an NT 4 host,
patched to service patch 4.

I've installed smbfs on FreeBSD.  This lets me mount SMB shares as Unix
file systems.  I've mounted \\controller\c_drive as
/usr/local/wine/drive_z.  This works in FreeBSD.  I can read and write
to files under that path, and they are created on the controller's hard
disk, as expected.

I've run "wine --winver nt40 notepad.exe", and that works fine.  Notepad
is able to read and write files on the 'local' C: drive, and the Z:
drive, and those files appear in the Unix file system as expected -- in
the case of the Z: drive they appear on the controller as well.

So far so good.

So I create a test scene in Lightwave.  The scene contains a description
of all the objects in the scene, their position, and so forth.  The
scene *also* specifies where the frames rendered by each node are going
to go.  For the time being, I turn this off.

Effectively, this means that each node is going to render each frame
it's given, but is not going to write the results to disk.  Instead, it
chews through the frame, and then dumps it, moving on to the next frame.
However, lwsn.exe is *still* going to write to the Z: drive, as it needs
to update the job? and ack? files that are mentioned on the command
line.

I then run lwsn.exe on an NT node (using the command line above), and
run it on FreeBSD like this:

    # wine --winver nt40 -- z:/newtek/programs/lwsn.exe -2  \
        z:/newtek/programs/job2 z:/newtek/programs/ack2

lwsn starts up on both hosts, and prints it's usual diagnostic information 
that tells me it's waiting for input from the controller.  Then it sits
in a loop waiting for input.

On the controller, I initialise Screamernet, which correctly finds both
nodes (one running NT, one running FreeBSD).  It assigns the frames to
each node, and I start the render.  Both copies of lwsn start processing
the files, updating the job? and ack? files, and so forth.  But they
don't render any finished frames.

This works fine.  I can see that the FreeBSD machine is successfully
loading the scene file, the objects, and so on (which all come from the
Z: drive -> /usr/local/wine/drive_z -> \\controller\c_drive).  It seems
to be doing the render correctly (it's taking the same amount of time as
the NT node), and it successfully tells the controller when it's
finished a frame and needs a new one.

So as far as I can tell Wine is doing the right thing, the Screamernet
is set up correctly, and lwsn can read and write to the Z: drive with no
problems.  CPU usage goes up to 99% during the render (which is
expected), and so forth.

Feeling bouyed by success, I stop the render, shut down all the
machines, and bring them up cleanly again.  This time, I change the
scene file, so that the finished frames will be written to
z:\newtek\renders.  I create this directory on the controller, and I make
sure that both the NT and FreeBSD node can write to it;

    # cd /usr/local/wine/drive_z/Newtek/Renders
    # touch foo

works, as does using notepad.exe to create a file in there.

I save the scene file, and run a copy of lwsn.exe on the NT and FreeBSD
nodes.

So the only thing that has change is that the scene now specifies where
to save the finished images.

The NT node does this with no problems.  It processes the first frame
it's given, writes it, then takes the next one from the controller.

The FreeBSD node doesn't.  The last few lines of output when rendering
the first frame it's given are:

    ...
    Integrating pixels.
    Rendering frame 1, segment 2/2, pass 1/1.
    Computing lens flare for Light (4).
    Integrating pixels.
    Writing RGB data to image file.
    wine: Unhandled exception, starting debugger..

All but the last three lines are identical to the previous run (where no
finished frames were saved).  As you can see, it gets to the point where
it should be writing the image data, and then Wine throws an "Unhandled
exception", and hangs.  Ctrl-C returns me to the prompt.

I can reproduce this 100% reliably.  If I go back in to the scene file
and make sure that the frames are not finished, everything works as it
should -- of course, if I do that then it's not terribly useful as a
render farm.

I'm confident it's not smbfs that's causing the problem.  Firstly,
because the job? and ack? files are updated correctly, and tests with
notepad show that apps running under Wine can write to Z: with no
problems.  Secondly, because I've tried with a scene file that specifies
that finished frames should be written to the C: drive instead.  But
Wine still crashes at the same spot in the process.

Anyone got this working?  A web search didn't turn up anything useful.
I've looked at the Wine Troubleshooting Guide, which didn't seem to have
anything that looked pertinent.  The Wine Debugging Guide is (sadly)
mostly empty at the moment, and the FAQ and Installation documentation
don't cover this sort of thing either.

I've had a look at the Codeweavers AppDB, which lists Lightwave as
working, but says nothing about the Screamernet component being tested.
A groups.google.com search for "wine lightwave screamernet" shows lots
of people asking whether it can be done, but no actual success stories
that I can see.

Thanks in advance for any suggestions.

N
-- 
FreeBSD: The Power to Serve             http://www.freebsd.org/
FreeBSD Documentation Project           http://www.freebsd.org/docproj/

          --- 15B8 3FFC DDB4 34B0 AA5F  94B7 93A8 0764 2C37 E375 ---

Attachment: pgp00003.pgp
Description: PGP signature


[Index of Archives]     [Gimp for Windows]     [Red Hat]     [Samba]     [Yosemite Camping]     [Graphics Cards]     [Wine Home]

  Powered by Linux