#Lantastic, WFW & Mirage
25 messages in this thread
Alan –
How's life with Lantastic? I guess I'm going to have an opportunity to
experience it, along with life with a PAR (just rec'd mine today, with the 1.6
gig Micropolis).
Do you know anybody who has successfully gotten Lantastic and Windows for
Workgroups (3.11) working? I'd be quite comfortable using WFW in Windows and
Lantastic for DOS (read: 3D Studio).
Any thoughts?
Echo James F. thoughts, from experience – posted some questions on the
Lantastic forum along these lines early last week – still waiting on an answer.
Also, picked up Mirage – great IPAS!
What's new and exciting?
re
Hello, Bob. How's everything?
My "life" with Lantastic has been just fine, thanks. With my little "rendering
window-herb garden" of three machines, things seem to work just fine, I'd
reccomend it for this sort of application.
WFW, however, I've heard mixed reports about. Contact Don Landis about the
problems he had with it. Just going back to Win3.1 fixed his problems, I think.
I don't remember exactly what went on there; he could fill you in. If you are
planning to use WFW strictly for Windows stuff and Lan6.0 for DOS/3DS (can you
do that?), then maybe there's no need for concern. Run it by DonL to see
exactly what happened with his system.
Congrats on the PARchase! I'm sure that you, along with virtually everyone I
know who has one, will have a total blast with it. (I'm writing frames to mine
as we "speak". <g>
New and exciting? I'd say the r4 anouncement is both of those things! I can't
wait to play with IK — it's been something I've been wanting to do for a long
time…
Hey, have a great meeting next week. I'd love to come up, but it looks like I
may be busy. But you never know…
Take care,
-Alan
I like "rendering window-herb garden". I'll have to add that to the list. I've
used the term 'render patch' for anything less than 6 cpus but 'Render Garden'
might be best. :-}
I've sent the term 'render farm' into Wired for their 'jargon watch' section.
(along with the term DECOMPRESS, relating to taking a vacation)
I've always credited Bob Bennett with the 'RF' term, at least I know that's
where I first heard it back when we were doing 'Bored Room'. (I think some of
it had to do with my wearing farmer's cover-alls, most of the time.) Anyone
know a different origin?
J-me
Hey, Jamie. How are you?
Nice seeing you at Siggraph, and nice seeing you up here so frequently now.
So, how long *did* it take you guys to get back to the Peabody Wednesday
night?<g> So much for Gary's "early night", and I never *did* get that birthday
drink with MicheleB. Martin and I actually hung with JoeF and LoriM<?> until we
just figured y'all just weren't gonna make it. Maybe next year<g>.
I have no idea who came up with the RF term, but I heard it first up here years
ago. Maybe someone in the SGI world came up with it…Or maybe it *was* BobB!
The "Window herb garden" is just the littlest farm I know of to describe my
modest system…
-Alan
>>(along with the term DECOMPRESS, relating to taking a vacation)
Believe me! As a heliox and trimix mixed gas diver decompression is NO
VACATION. <BG>
As Alan stated I had many strange problems with WFW and large files. These
problems can be eliminated using bus mastered ethernet cards. A friend of mine
figured it out and got Robert Metcaff to explain what the problem really was.
Specifically, The WFW 32 bit networking system has trouble keeping the packets
adresses in order using conventional ethernet hardware. ( the tga's end up
across the net with sections of the picture rearranged, PageMaker files have
rearranged letters making the words in the text files mispelled. Some cards
such as the Kingston cards don't have the problem. For a small network such as
mine the solution was to dump WFW and go back to Lantastic AI 5.0 with the
windows running under it. I have complete transparent operation of DOS and
windows 3.1 simultaneously with full network features under windows. Aside
from the bugs compatibility of generic ethernet cards WFW always kept reminding
me that I was using a network with constant reminders like "that device is not
shared or when I was in dos I couldn't access its resources with another
machine running windows. With Lantastic its like I'm on one big computer that
doiesn't care whether other machines are running windows or not.. I've decided
that I will wait for good reports about Windows NT before switching from
Lantastic/windows 3.1.
Robert,
My network rendering setup consists of a WFW server, and 4 slaves
running WFW Add-On for MS-DOS (allows DOS machines to be clients to a windows
machine). We also have a PAR on the server. We've come across a lot of
problems in doing network rendering – mostly with strange behavior from the
slaves…
As far as rendering to the PAR drive over the network – you can't do it.
Everyone told us to get NDUMP – to let us do this. The problem with NDUMP is
that it only
will output the frames to the PAR drive SINCE THE LAST FRAME THAT THE SERVER
HAS RENDERED. Therefore, let's say you have a 300 frame animation…
Your server is up to frame 100 and the other machines are rendering away…
when the server finishes with 100, NDUMP will gather sequentially frames 0-100
and output
them to the PAR. "Great." – "Ya, well…" IF, in the meantime, the other
slaves finish the process frames (101-300) – THOSE FRAMES WILL NEVER GET TO THE
PAR,
because the server now thinks the process is done, and doesn't pick up another
frame… see the problem? I've written my own DOS batch file that fixes this,
and we've
sent back our copy of NDUMP. With the way that it is, I can't afford the chance
of losing a bunch of frames every night I render. The extra time to copy them
over in the
morning is a pain. That's why we tried NDUMP in the first place… Oh well,
maybe an update is coming…
-Glen
Glen,
I'm very much interested in your approach to getting frames on several machines
off to the PAR. My par is on a seperate machine which doesn't render and of
course that means NDUMP won't work there either. I was trying to write a
program which would do it but realised that machines that are rendering can't
be searching for new files unless its done on a DOS command line in VP. This
gets very awkward if it would work at all. Ideally I would like to have a
program on the PAR which will look for the appropriate images and load them. Do
you think this is workable. I've got several little programs which will run
batch files and some I've customised for transferring images to the PAR but it
would be nice to do it over the network. I don't want to slow the system down
by having the PAR drive tie up the network looking for images though. Got any
ideas?
Thanks,
-JE
Didn't realized NDUMP had a technical problem. I was about ready to order it.
I'm sure Greg P. will jump in to explain how he resolves this problem. Hmm?
GREG…? For now I'll stick to rendering to the DOS drive and transfering to
the PAR later.
As far as I can tell NDUMP does what its supposed to do, it just won't work in
my configuration. I was unaware of the scenario Glen expressed.
-JE
Don:
See my posting. There is no technical problem with NDUMP, just the way 3D
Studio calls IXPs.
Greg Pyros
I understand and we'll see how the dos version goes before I jump on the NDUMP.
I would have the same problem that others have been having as I seldom run 3DS
on the machine with the PAR when network rendering. Only on rush jobs where I
tie up all machines and go to the movies! NOT!
Don:
OK, the DOS version of NDUMP _should_ (Gus, we've been committed!) be out this
week. Free by e-mail for registered users.
By the way, is this considered an upgrade or a downgrade? <bg>
Greg Pyros
I guess I can holster the compiler for now! 😉
Now I have to build me a network at home…
J-me
I agree, I had similar problems with Ndump (sorry Greg) and simply stopped
using it. I was working on a DOS version that wouldn't require 3DS to be
running (and you could use on a lesser machine) but that project died when I
split the 'desk.
Once again, a need that is open for a developer to step in…
J-me
Jamie,
As you were working on a DOS version of NDUMP maybe you can answer a question
that halted my progress.
My concept was to have a reserved area on a server (without 3DS running) and a
program on that system that checked to see if the next sequentially ordered
frame had been sent from the various networked systems.
I reasoned it would be difficult to have that system run efficiently with a DOS
version running in the background while 3DS was rendering.
The question I had was if the CPU on the server is constanly checking to see if
the next frame has been sent to the reserved area, wouldn't that slow down or
stop frames from being sent to that reserved area? I thought about putting
"pauses" in, but "pauses" don't release control of the CPU.
What do you think? I'd be willing to try a different approach.
I'm using LAN 6.0 BTW
Thanks,
-JE
Glen:
>> [NDUMP] Oh well, maybe an update is coming…
You've described the problem well, however your analysis does not compute! <g>
NDUMP, being an IXP, can only output those files while that process is running.
Obviously, if your NDUMP machine is rendering frame 100, the highest possible
frame that could be on your disk is 99. So NDUMP will copy those frames to
whatever (PAR, Laser disk, ZIP file, etc.) and then finish rendering and saving
frame 100. If your other frames finished the renderings by then, 3D Studio
would not render another frame, so NDUMP.IXP would not get called to pick up
those frames.
If you have X machines rendering Y frames, assuming all of the machines are the
same speed or slower than the NDUMP machine, NDUMP will get to frame Y-X. What
we do here is just to render an extra X frames of the sequence, and this will
always cause your 'important' frames to be properly processed. If you get too
many copied to the PAR, you can always delete them! My attitude is that I
would rather have the machines work a bit harder at 3:00am while I am sleeping,
since they would then just stop and wait idle anyway.
Works great, every time.
There are hundreds of people happily running NDUMP every day, and only one has
called to complain. They were trying to run NDUMP on a '386 with all the other
machines on the network Pentiums. Was that your group in S.D.? <g>
Greg Pyros
Greg,
Thanks for the comments… My problem, though, is that with my network
configuration, I don't want to have my server (running WFW) trying to render.
It's there
that we get into all of the problems with 3DS running under Windows. I
understand your comment about adding the extra frames and assigning them to the
server, I know that will work (still kind of a "work-around" though.) but since
I want my server to be a server and not render, I'm back to where I started…
Hmmmm.
-Glen
Glen,
>> but since I want my server to be a server and not render… <<
I'm in the same predicament. I trust Greg will be able to come up with a
solution, if not I'd be happy to write something given a little protocol
guidance.
-JE
JE:
We hear you. We are working on it right now, will have something for you later
this week. Such service!
Greg Pyros
Greg,
>> Such Service. <<
What can I say that wouldn't sound like well deserved flattery? <g>
🙂
-JE
Glen:
Actually, changing NDUMP to a dos-level program would be a quick change if you
didn't want 3DS running on that machine. Let me look into it.
Greg Pyros
Greg,
<Let me look into it.>
Thanks. I'm sure you folks are up to the challenge. Of course, if the PAR
people wrote a network compatible IDE driver, we wouldn't be
having this problem… 🙂
– Glen
Glen:
Actually, the problem lies in the fact that the PAR already looks like a
re-directed drive to the DOS operating system. And the old rule that you
"can't re-direct a re-directed drive" holds true here.
Besides, even if you could see the PAR from all systems, you'd still need NDUMP
to put the files on the PAR in order! Otherwise, you'd REALLY have a problem!
Greg Pyros