#field-ordering
24 messages in this thread
Hi Jonas,
This is Dave@Sony. We have already checked the log files for
the renders and they confirm that specific machine(s) are not at
fault. The log files showed that the same machine will post a
corrrectly rendered field order and the next frame it renders wil be
backwards and so on. And the problem has only occured in the last
week or so, about the same time we started upgrading to r.4. We
currently have about half of our machines at r.3 and half at r.4, but
again, the machines with r.3 will post the problem just as often as
the machines with r.4. Any ideas on this would be appreciated as
soon as possible, given our current crunch-time. Thanks.
Yikes Dave!,
<< Any ideas on this would be appreciated as soon as possible, given our
current crunch-time. >>
The crunch-time factor throws a big twist into this production
problem…
I'd like you to run a test. Send a project to the specific machine
that produced the reversed field order file with network rendering.
Send the identicle project file to the same machine with the same
frame range using batch rendering. Are the files all correct or did
the same frames flip for each machine or did other frames flip? If
you send it again, (assuming you found a flip), did the same frames
flip? Now, if you render the sames project file from within 3ds while
in "master-dongled" mode, are the resultant frames identicle to the
rest. .. I know that is alot of testing but I'll need this
reproducable case for the engineers….
In the mean time, to help document your environment,,
is everything launched from network rendering within R4 or are some
jobs launched through R3?
are you able to identify and rerender the problem frames quickly?
what are the total #of good and bad frames?
how many machines are involved in network rendering? are they all R4 or
mixed with R3?
———————————————————–
Now to deal with the crunchtime, you've suggested that R3 machines involved in
network rendering get affected. There was some modification to the 3ds.exe with
regards to field order during the R4 development, but I thought it was
localized to batch rendering and field order. I'm hesitating the recommendation
of reinstalling 3ds on all of your machines. However, I wonder if you may want
to create several seperate network queue directories to see if any of the
clusters are "clean" of these symptoms.
I'd like you to mail me your current logfiles and notes identifying the current
pattern, please.
I use R4 at my desk, but my main network rendering machine is running R3 but I
don't put the volume of frames out that you do and I haven't seen this yet.
I'll be logging in later tonite and I expect Gary to also.
jonas[adesk]
Dave:
>> We currently have about half of our machines at r.3 and half at r.4…
That may be your problem! The network files are a bit different,
actually I'm surprised that you aren't having more problems. Upgrade
the rest of your machines, or take the new ones back to R3, and let
me know if the problem goes away.
Greg,
Do you have anything on the different network file formats that you
could pass to us?. We just upgraded R.4 and have numerous R.3 slaves.
Am in the middle of a 7000 frame job and will investigate to see if
we are having the same problem. Will lay sequence to tape tomorrow
and keep you informed.
P.S. "Render Jungle" is coming… We are estimating January release.
Also, call me if you need additional "horsepower". Our facilities
(and capabilities) are improving every day!
Hello Matt,
Have you got any news or photos of a machine? I have been
talking to James Murphy about it. I am as interested as you can get.
Do you take cars in trade? How about a used President…I believe we
have one looking for a job soon. Seriously, I'm hoping a Jungle makes
its way to Los Angeles real soon. The natives are restless.(g)
Sanford,
Thanks for msg – no info yet. Looks like Jan 95'. Some components are not
finished.
matt
Remember the ol' song…."All I want for Christmass is my Jungle Jim, my Jungle
Jim, my Jungle Jim…or was it something about teeth? (some people will go any
extent to make a bad joke)…but it's true, I want my Jungle!
Sanford
You bet! Let's get a new one!
Chris
AM Labs
Hey Chris,
Do you have access to a "Jungle?" What is the 7,000 frame job you guys
are rendering that Matt talked about? Is it a secret?
Sanford
Not a secret. It's for an automated highway system someone is going to
try to sell to congress. The Jungle is doing well, still trying to
tweek it out though.
Chris,
Is it going to be Novel or will lyou be able to run out of
Lenix, a PC based variant of Unix?
Jonas,
We'll try to do all the tests you've suggested, but it'll take some time.
In the meantime, we upgraded all our pentiums to r4 and rerendered some of our
stuff.
The bad news is the problem is still there. The good news is that ALL of the
frames are reversed. Soo…. before we run the gamut of tests you suggested,
were going to change the set file field-order parameter on all of these
machines to 2 (it's now at the default, 1) and see what happens. We'll let you
know later today.
Thanks
Tim Miller & Dave Thompson@Sony
Hi Tim and Dave,
<< We'll try to do all the tests you've suggested, but it'll take some time.
In the meantime, we upgraded all our pentiums to r4 and rerendered some of our
stuff. The bad news is the problem is still there. The good news is that ALL of
the frames are reversed. Soo…. before we run the gamut of tests you
suggested, were going to change the set file field-order parameter on all of
these machines to 2 (it's now at the default, 1) and see what happens. We'll
let you know later today. >>
Staying tuned..
jonas[adesk]
Jonas,
I have been having field order problems as well on my network. I haven't
mentioned them because I've learned not to bother mentioning any problem that I
have until someone else has it too.
I've got three machines — all with r4. All the .set files have the default
"field order = 1" value. But: sometimes the log file will show the field order
as "0" on all machines. No matter what I do (restart all machines one by one,
delete the job and start over, etc) it will continue as "0".
The interesting thing is that I believe that the log file showing field order
as "0" is an error. It appears that the actual field order is "1" — in spite
of what the log file says.
I can't be sure about this because I don't know how to determine what the real
field order is. I have rendered a targa job with the field order set as "1" and
shown as "1" in the log file and then I have re-rendered some of those targas
which suddenly show up as field order "0" in the log file. When I brought the
targas into the PAR, I expected to have problems between the two groups but
there is no noticeable differance — so my conlusion is that the log file is
not accurate.
Alec Jason
P.S. I need to know what differences there are between r3 and r4 regarding
network rendering. I have still had other severe problems during network
rendering and I'm wondering if I should have done something more than just copy
over the r4 3ds.exe files onto the other two machines.
Hi Alec,
<< I can't be sure about this because I don't know how to determine what the
real field order is. >>
I create a cube and set 2 color keys for a light at frame 0 and frame 1.
(seperate color values). Fill the viewport with the box. Set the order in your
3ds.set and Render frame 0 with fields. Do this for each field order. Boot
animator pro and pan to the top two scan lines. They should be the two
different light colors. The two files should be different, reflecting the field
order. The light color will help you identify the true field order.
Please post your results.
jonas[adesk]
Hi Jonas,
I tried to follow the procedure you suggested but I don't think it is helpful
in addressing the actual problem that occurs intermittantly during network
rendering. And, after rendering .tga's with different field orders, Animator
Pro cannot be used to view them because they are 24 bit.
I did render them as you suggested and looked at them in a Windows program and
they showed (I think) that field order 0 means the first frame (keyframe 0) is
first and field order 1 means the second keyframe is first.
But the actual problem occurs during network rendering and it does not appear
to be related to the .set file values. Sometimes the field order will show up
as 0 and sometimes as 1. I can't make it happen. But, as I mentioned
previously, I don't think the field order shown in the log file is not the
actual field order — sometimes.
Also, over the weeks, I have learned some things about my chronic network
problem. The actual problem is that the server disk (where the 3ds\network
directory is located) is intensely activated by the slave machines on the
network. Each machine hits the disk for about three seconds — apparently to
update the 3dsnet.ctl file. Each time this occurs, the server is almost brought
to a halt: mouse movements, screen redraws, etc are extremely slow during these
updates. Sometimes the time period between these slave updates vary between 70
seconds (for each machine) and in other days the time interval may be as little
as two or three seconds (which causes me to shut everything down and start
over).
I need to know how often these updates are _supposed_ to occur. Can you please
find out this information?
Thanks,
Alec Jason
Hi Alec,
<< tgas >>
You're right. I missed the "bring the image down to 256 colors" step. My
method, when working, is a valid and visual test of field order. (IMO)
<< need the info.. >>
I do not have any access to the internal 3ds engine source stream. Sorry..
Gary?
You'll have to put some test cases and data together, and then we can pass it
by Tom to get his opinion.
– G
Hi Alec,
Gary says..
"<< You'll have to put some test cases and data together, and then we can pass
it by Tom to get his opinion.
– G "
and you say ..
<< But the actual problem occurs during network rendering and it does not
appear to be related to the .set file values. Sometimes the field order will
show up as 0 and sometimes as 1. I can't make it happen. But, as I mentioned
previously, I don't think the field order shown in the log file is not the
actual field order — sometimes. >>
Somehow we need the "sometimes" to turn into a solid reproducable test case for
Tom..
Does anyone else, with a similar networking configuration to Alec, see similar
trashing of the server?
I'll also forward this to QA.
jonas[adesk]
Jonas,
The field-rendering problem, aka the field-rendering log files problem,
persists but I think I've solved the network rendering problem. Someday after
I've "put some test cases and data together" I'll tell you what the cause was.
Thanks,
Alec Jason
Hi Alec,
<< Someday after I've "put some test cases and data together" I'll tell you
what the cause was. >>
Thanks.. I'll look forward to it.
<< Bay Area User Group.. >>
I heard that was you standing/sitting in the back of the room. Had I known, I
would of introduced myself..
jonas[adesk]
Hi Jonas,
I wish I had known that _you_ were at the meeting. Oh well, next time!
Alec Jason
If you would always remember to wear your "Will work for PAR" sign
when you go out in public, people would be able to recognize you.
Alec:
>> I'm wondering if I should have done something more than just copy over
>> the r4 3ds.exe files onto the other two machines.
Yes, you should have! There are also a handful of other files that are new and
needed. What I did here was just to do a full installation on one machine, get
everything working properly, then do an "xcopy /s" of the entire thing out to
the network. I then wrote a batch file called update.bat which has the proper
commands to copy everything up to each individual machine when run. The batch
file creates the directory structure on the new machine and copies all of the
old IPAS processes over to the new directory. Then it copies everything from
the network over that – this insures that all my purchased IPAS routines get
moved over, and that the newer ones that came with R4 got copied over the old
ones.
Sure makes it easier to update a bunch of machines, and it makes sure that
everything works properly. Then just delete the R3 directory structure when
you are ready.
Greg Pyros