#Net Render != Local Rndr
18 messages in this thread
We're having problems with several aspects of rendering over the network
producing different (in some cases, WILDLY different) results vs. rendering
locally.
For instance, I have a wireframe material set to Units applied to a certain
object. The units setting is wide enough that the object appears to be made of
beams, not wires. When rendered locally, it comes out fine. When rendered via
Net Queue, it acts as if it were set to 1 Pixel instead of my Units setting —
the object looks like it's made of fine wires that don't recede in thickness
according to perspective — just what one would expect from Pixels Wire vs.
Units Wire. I checked both the .MLI and the mesh versions of the material
(using Get from Library and Get From Scene) and they are identical, both set to
Units Wire.
Also, NEW-SUBTRACTIVE-TRANSPARENCY settings are not transmitted, so that all
network render farm machines have to have their 3DS.SET files edited and then
exit and restart 3DS just to set the transparency type. No fun.
SMOKE.SXP doesn't seem to hold its settings when rendered via Net Queue,
despite SMOKE.SXP (and all IPASes) being copied to each machine's local
3DS3\PROCESS (and 3DS3\MAPS in the case of SXPs) directories, with Read Only
attribute set just in case.
More seriously, 3DSr3 appears to open its bitmap files with Full Access
instead of Read-Only Access, even when rendering on a network. This causes
machines to fail unless I remember to do "ATTRIB +R" on every single bitmap
image used in the animation. Failure to do so causes one machine to start
rendering and all others to fail at the "Readying Materials" stage with a "File
Access Denied" error in the Net Queue Error Log. Clean-and-Update then causes
another machine to succeed and all others remaining to fail, and so on — the
process either has to be repeated for each machine on the network, or else I
have to stop, do "ATTRIB +R *.*" on every directory in the Map Paths being used
for this animation, and restart. Yes, SHARE.EXE is loaded on all machines:
servers, workstations, and render farm beasts of burden. So what gives here?
Surely you didn't release a major network program that isn't smart enough to
open files as Shared Read-Only Access unless it really needs full write access
(like when saving a file)!
Marion,
<< Rendering is wildly different >>
Thanks for the details. I'm forwarding it to all
involved QA members.
jonas[adesk]
I've experienced this file sharing error, too. I'm glad I'm not the only one,
I was beginning to think I was crazy (actually, a few other folks have
mentioned this, too) 😎
John Tissavary (La Luna cie)
Marion (and John Tissavary) – what is(are) the network you're using? I have
the impression after talking to Brian Rudolph that specific networks handle
sharing differently. We're trying to accummulate data to test this theory.
Thanks.
Nik
We're using LANtastic 5.0. But file sharing is handled by SHARE.EXE and the
extensions to the INT 21 MS-DOS function call BIOS routine that it adds to
MS-DOS, not by the LAN software.
I know exactly what the problem is. The problem is that 3DS is failing to
set the "SHARED READ-ONLY" access flags when it calls the INT 21h File Open
call. That flag ONLY applies to file sharing (whether networks or any sort of
multitasking or both), and is ignored if there is no SHARE.EXE loaded.
The point is, any number of users (be they LAN workstations, tasks on the
same machine, or whatever) can open a given file for READ access at a time,
since there is no possibility of it being changed while another user is trying
to read it. But if any ONE user opens it with WRITE access enabled (and the
default is to enable write access, unless that flag is set!), then any other
attempts to open the file in any mode will fail with an "Access Denied" error
message, unless the programs in question are all designed for shared
database-style record-locking (actually byte-range locking) access. Since
3DSr3 just reads in the whole bitmap file, it does not perform byte-range
locking (that's only useful for multi-user database and similar apps).
Therefore, the whole file is locked if any one user succeeds in opening the
file with write access enabled (whether or not the program actually writes to
the file).
Regardless of the type of network or multitasking system, opening a file in
READ-ONLY ACCESS mode will permit multiple users to open it in that same mode.
But once any one or more users open the file in that mode, no one can open it
with WRITE ACCESS enabled until all users who have the file open in READ-ONLY
ACCESS mode have closed it.
If the file has the READ-ONLY Attribute marked in its directory entry, then
the file can only be opened in READ-ONLY ACCESS mode. Any attempt to open it
in any other mode will instead drop down to this mode (unless the attempt was
for Write-ONLY mode, in which case the open will fail with an Access Denied
error). Thus, performing an "ATTRIB +R *.*" on the contents of all MAPS-PATH
directories and the IMAGE-PATH directory will kludgingly "fix" (bypass) the
problem.
In summary:
INT 21 receives an OPEN call:
Is READ-ONLY mode requested?
Yes: Does anyone have the file open for WRITE ENABLED access?
Yes: Fail — Access Denied
No: Succeed and return to program with file open.
Is WRITE-ONLY mode requested?
Yes: Does anyone else have the file open in other than SHARED WRITE mode?
Yes: Fail– Access Denied
No: Succeed and return to program with file open.
Is the file marked READ-ONLY in the directory?
Yes: Treat the file as if READ-ONLY mode was requested (see above).
Does anyone else have the file open in other than SHARED WRITE mode?
Yes: Fail — Access Denied
No: Succeed and return to program with file open.
Because 3DSr3 is apparently not specifying any ACCESS parameters, the
decision tree skips to the bottom question, which thus fails if anyone else
(say, any Network Rendering Slave) has the file open, regardless of the mode
(remember, Shared Write is only used by multi-user databases).
This really needs to be fixed ASAP, IMHO.
Jonas has it on his list of issues.
– G
I am getting reALLY strange results when network rendering via net
queue EVEN when only doing it on one machine. For instance to render
the morph duck off the WCT-CD, if I use net queue, every couple of
frames is rendered dark, as if the lights were on extra low, then
after a while, every frame becomes dark. The same thing happens if I
do it across a few machines, some frames come out 'dark' looking. It
would not appear to be a file access problem as it happens when using
just one machine to do the render. We are going to be demonstrating
the networking capabilities at a show next week, but it don't look
good at the moment. Any ideas???? Thanx…Peter
Peter:
A couple of things you need to look for.
1) Make sure that none of the machines has a 3DS.PRJ file on it.
2) Make sure that all 3DS.SET and 3DSNET.SET files are identical with respect
to things like input-file-gamma and output-file-gamma.
3) Make sure that all your maps are identical, and are all accessed by the
program from the same place.
We just create one file here with all our parameters, then copy it to the
network, and bring it up on every machine. Then just cut-and-paste the
Vibrant display info and the NET-NAME and number lines.
Greg Pyros
Thanks guys …but we found the problem last night…a work experience chappie
had put a 'cracked' version on our server, we didn't realise until I checked
the 3ds.exe filesize.
I re-installed and all was okay (except for 8 hours of rendering down the
gurgler).
Rest assured his school report will have a few things on his 'permanent record'
Thanx again for the suggestions, they will come in handy as a checklist if we
have any future problems.
Peter
Michael,
>> a 'cracked' version on our server<<
You may want to ZIP that 3DS.EXE and send it to your 3DS dealer (or an Adesk
rep on the forum) so that they can follow-up on the SN#.
Ang
—–>>>>> Thanks guys …but we found the problem last night…a work
experience chappie had put a 'cracked' version on our server, we didn't realise
until I checked the 3ds.exe filesize. I re-installed and all was okay (except
for 8 hours of rendering down the gurgler). Rest assured his school report
will have a few things on his 'permanent record' Thanx again for the
suggestions, they will come in handy as a checklist if we have any future
problems.
Yeah, I've seen that file. It seems to work ok in the modeling screens, but
when you render it replaces the default material with a grey/black type
material. Also, the overall brightness of the scene is diminished.
A text file I saw with that file said that it was "cracked" by some commercial
cracking company in Canada somewhere. So goes the life of the pirates…
Greg's suggestions are right-on. It sounds like you don't have your gamma
correction parameters matching on all of your machines.
– G
Thanks for your explanation of the read-write issue that seems to be a
3DS problem. Good explanation, well written. And Jonas has it…
Glad I could help, and I like the very quick response. Keep up the good
work, folks. 🙂
Nik
Sorry, I'm not sure if this is the correct thread. If this is about the Int21
and share problem, has it been resolved?
Thanks
JB
Note that none of the preceeding explains the differences in Wire Mode
(Units vs. Pixels) rendering, or the failure of SMOKE.SXP parameters to follow
the network, or the failure of NEW-SUBTRACTIVE-TRANSPARENCY to follow, or
gamma, etc.
I'm pretty sure the last two are because those functions aren't stored in
the .PRJ file. My suggested fix (which would require no UI changes, and thus
should be palatable to AutoDesk) is to save an additional .NPM (Network
ParaMeters) file each time a Net Render is initiated. This file would pass
information not stored in the .PRJ which could affect rendering in any way,
including overrides for gamma settings, NEW-SUBTRACTIVE, any other parameters
(AA-KERNAL, for instance), etc. which could possibly make even one pixel's
worth of difference. The Slaves would read this file and set the appropriate
parameters after loading the .PRJ for each frame.
Marion,
<< network rendering insights and wishes..>>
I'm forwarding your insights to all involved.
thanks.
jonas[adesk]
I am also using Lantastic 5.0, and Marion has summed up the source of
the problem beautifully (thanks <g>). This seems like an easy fix,
and it is definitely needed. I cannot tell you the time it wastes
having to baby sit the network everytime I start up all my machines
on a big rendering project. This is also the reason that rendering
VP composites causes slaves to fail after rendering several frames.
There is ALWAYS a file sharing error in play. Very inefficient.
John Tissavary (La Luna cie)