#3ds rendering stall
18 messages in this thread
I have 3DS version 4.0 running on a Gateway P5-100. Sometimes during
rendering, the system stalls while transforming objects. The system will allow
me to escape out of the rendering process, and then restart from the point it
stalled. It will then run fine for various numbers of frames before stalling
again. I had similar problems due to a power saver in the autoexec.bat, and
due to 32 bit disk access, but I fixed both of those problems. HELP!! Its
tough to babysit the machine for 30 hours of rendering.
Steve,
You most likely have POWER.EXE in your config files. Remove that line and
everything should be fine.
-Brian
That problem was a couple of months ago. That command was removed from my
config.sys file. In my earlier message I reffered to that problem in my
autoexec.bat, but I was mistaken, it was the Power.exe command in my config.sys
that I fixed earlier. Thanks for the try. Any more ideas?
<<Any more ideas?>>
If the stall is happening durng the tranforming objects stage, the only
reported problems are with POWER.EXE or other power saving features. Is the
stall still happening at that stage in the rendering? The other most common
problems would be memory conflicts. Have you tried to diagnose for those?
-Brian
The stall only occurs during transforming objects, and it occurs randomly,
unlike the problems we previously encountered with POWER.EXE. It will render
correctly for hours or days, and then start experiencing problems once every
hour or two. However, when we start rendering at the frame it stuck on, it
never sticks on that frame a second time. We have had numerous problems with
our system not just with 3DS, and although I have checked many things I'm not
sure what memory conflict checks I should, or have checked.
<<The stall only occurs during transforming objects, and it occurs
randomly, unlike the problems we previously encountered with
POWER.EXE. It will render correctly for hours or days, and then
start experiencing problems once every hour or two. However, when we
start rendering at the frame it stuck on, it never sticks on that
frame a second time. We have had numerous problems with our system
not just with 3DS, and although I have checked many things I'm not
sure what memory conflict checks I should, or have checked. >>
Steve,
sorry, I've been out of the office for a few weeks unexpectedly. Did you solve
this problem?
-Brian
>> <<The stall only occurs during transforming objects, and it
occurs randomly, unlike the problems we previously encountered with
POWER.EXE. It will render correctly for hours or days, and then
start experiencing problems once every hour or two. However, when we
start rendering at the frame it stuck on, it never sticks on that
frame a second time. We have had numerous problems with our system
not just with 3DS, and although I have checked many things I'm not
sure what memory conflict checks I should, or have checked. >>
Steve,
sorry, I've been out of the office for a few weeks unexpectedly. Did you solve
this problem?
-Brian <<
Humble request to attach to your thread? I have a similar problem with 3DS v3
hanging during rendering animation. The problem is intermittent, aside from
usually happening at the worst possible time, like when it was on the last
frame of a 7 hour render, I had just called the client so say all O.K., and it
hung 🙁 … I/ve kept the animations pretty small (60 to 120 frames) because
of these problems, which besides being costly, is a pain.
I'm running a 486DX66, 36mb RAM, QEMM 7.04, DOS 3.2, Stacker 3.0. Video card
('cheap', but O.K.) is a Spea V7 Mirage (S3 chip). Free disk space varies, but
try to keep 3x the estimated .flc file size free (on the destination drive for
the flic) to allow for temp files.
Any hints, help or otherwise most appreciated.
Cheers,
Chas
-Charles Dixon
<< I'm running a 486DX66, 36mb RAM, QEMM 7.04, DOS 3.2, Stacker 3.0. Video
card ('cheap', but O.K.) is a Spea V7 Mirage (S3 chip). Free disk space
varies, but try to keep 3x the estimated .flc file size free (on the
destination drive for the flic) to allow for temp files.>>
Depending on various paramaters in the animation, and how much RAM you have. 3
times the final size of the FLC might not be enough. If you are using HIGH or
medium palette modes, you will probably need more hard disk space than that.
Try rendering to LOW or CUSTOM palette. When you freeze like this, what does
your status say about paging to disk? Can you render the exact same scenes at
a lower resolution? Or if you turn off mapping? These would indicate you are
running out of disk space. Also, we don't recommend the use of Stacker or other
disk compression programs. While many people use them with no problems, there
have been reports that these can sometimes get in the way of Phar Lap writting
the temporary files.
-Brian
Brian,
Thanks for the quick response re: animation hangs
>> << I'm running a 486DX66, 36mb RAM, QEMM 7.04, DOS 3.2, Stacker 3.0…. >>
>>Depending on various parameters in the animation, and how much RAM you have.
3 times the final size of the FLC might not be enough. If you are using HIGH or
medium palette modes, you will probably need more hard disk space than that.
Try rendering to LOW or CUSTOM palette. <<
I usually use low palette.
>>When you freeze like this, what does your status say about paging to disk?
Can you render the exact same scenes at a lower resolution? Or if you turn off
mapping? These would indicate you are running out of disk space.<<
I use lots of maps, especially reflection. Running 32MB RAM, the machine
still often pages 20MB to disk (I know, get more RAM… <g>)
>>Also, we don't recommend the use of Stacker or other disk compression
programs. While many people use them with no problems, there have been reports
that these can sometimes get in the way of Phar Lap writing the temporary
files. <<
I was not aware Stacker could interfere with the temp files. I have had
problems with Stacker in the past when using Stacker's 'de-fragment' utility to
de-frag a Stacked drive — like corrupting *.prj files I really needed. Give
Stacker its due though, it hasn't harmed old *.prj files I don't care about —
they are safe as houses….
I recently installed a SyQuest 270mb removable drive to my system — _not_
Stacked. Perhaps using this as the target disk for rendering — for the temp
dir too? (although I am wary of that option since the "drive" is not always
there/installed, ie. removed).
Thanks again for the advise,
Cheers,
Chas
-Charles Dixon
<< I recently installed a SyQuest 270mb removable drive to my system — _not_
Stacked. Perhaps using this as the target disk for rendering — for the temp
dir too? (although I am wary of that option since the "drive" is not always
there/installed, ie. removed).>>
That would certaintly remove some of the strain on your hard disk. Especially
if you use a new cartridge. remember, though, that the temp files the FLC
creates are not the only temp files written. Pharlap writes files to the drive
specified in the CFIG386 settings.
-Brian
Brian,
>> That would certainly remove some of the strain on your hard disk.
Especially if you use a new cartridge. remember, though, that the temp files
the FLC creates are not the only temp files written. Pharlap writes files to
the drive specified in the CFIG386 settings. <<
Thanks — that is a useful piece of information. I'm aware of the temp file
location setting in CFIG386. When you referred to the temp file conflict with
Stacker, I thought these temp files were the ones you were referring to.
Your info means I can maintain the temp dir location set in CFIG386, i.e. on
the permanent drive, and safely render to the Sysquest drive, to which I
assume, Pharlap will automatically send the flc related temp files,
irrespective of the CFIG386 setting.
By the way, this problem has been a serious headache for a long time. Your
help is really appreciated — I wish I had asked sooner!
Cheers,
Chas
ps: If you are ever in Newcastle upon Tyne I'll buy you pint! ;-}
-Charles Dixon
I had a similiar problem using Personal Netware. The Map paths embedded in the
project to be rendered pointed to drives that didn't exist in the context of
the slave. When I removed these, it worked.
>> I had a similar problem using Personal Netware. The Map paths embedded in
the project to be rendered pointed to drives that didn't exist in the context
of the slave. When I removed these, it worked. <<
What a timely reply particularly re: >> pointed to drives that didn't exist
<<!!
Brian Rudolph's [Adesk] reply/advice about the locations of the different
types of temp files/locations lead me write a short COM program earlier this
week for determining if a drive is available. It returns an errorlevel code,
which a batch file can then use to help select the appropriate *.SET file; ie.,
if the drive is available, use the SET file which uses that drive, if not then
use an alternative SET file. I've started using it with a 3DS SET file to send
related TEMP files to the removable drive when it is there, an more
importantly, not sending TEMP files there when it is not there ;-). Whether
the notion of sending the TEMP files to the removable drive _actually_ works is
another matter…
The program, ISDISK.COM, has only been tested on my machine. So far it has
worked with a CDROM, SYSQUEST removable drive, and the floppy drives. It will
only run in DOS due to its use of DOS interrupts, however running it from a DOS
window in Windows works, too, of course.
If anyone in these environs think they could use it, I will load it along with
the C source code onto one of the ASOFT libraries for either free usage or an
all-expenses-paid trip to somewhere sunny and warm 😉
Cheers,
Chas
-Charles Dixon
I have tried several fixes since our last discusion, but with no luck.
As a matter of fact, I spent last weekend trying to pin down the
problem on a file which the problem is happening repeatedly on. I
have 32MB of ram, and only 10mb is being used for this animation.
Thus, no swapping is occuring. I am rendering to a Micropolis hard
drive using a par board. I thought it might be a problem with the
micropolis, so I tried sending the files to my normal hard drive.
Same problem. I also tried changing the block limit settings on the
PAR board, and that seemed to fix it for a while, but then back to the
same old thing. The PAR book indicated that this could cause
failure, so I am continuing to play with the settings. However, I
haven't had any luck so far. Luckily our Memorial Day Weekend
weather was terrible, so I've had plenty of time to struggle with
this one. Help if you can,
<< I am rendering to a Micropolis hard drive using a par board. I thought it
might be a problem with the micropolis, so I tried sending the files to my
normal hard drive. Same problem. I also tried changing the block limit
settings on the PAR board, and that seemed to fix it for a while, but then back
to the same old thing. >>
When you were rendering to the regular hard drive, were the drivers for the PAR
board still loaded? I would try booting without any of the drivers, and render
to the regular hard drive. See if that solves anything.
Also, what about a clean boot (FILES and BUFFERS only) rendering to the regular
hard drive. Does that still have the problem?
Also, does your computer/motherboard have any powersaving features that are
built into the BIOS? Is it possible there is still a "green" feature that has
not been turned off?
-brian
I think you isolated the problem. After your messeage, I exited and the
re-entered 3ds normally. However, I did not load the PAR PXP routine as I
normally would. I then rendered TGA's to my hard drive. Seven hours later,
all 280 frames rendered without a hitch. I then loaded the PAR PXP routine and
rendered a known trouble spot to my hard drive. No glithes? I then rendered
the same section to the par hard drive. It stalled after 2 frames, confirming
that last nights rendering success was not a fluke. Any ideas on where to go
from here? At least I feel like I'm gaining now, THANKS.
-steve
<< Any ideas on where to go from here? At least I feel like I'm gaining now,
THANKS.>>
Not really, I don't use that IPAS routine. I know the IPAS routines that Greg
Pyros wrote for the PAR are very stable. I've never had any problems using
those.
-Brian
PMJI–
but I have a similar question to the one answered by this post:
>> Not quite. Whatever you have set for -swapdir in your CFIG386 settings
will be where Phar Lap writes those temporary files. Then there are another
set of temporary files that you can direct the location. This is the TEMP=
variable in the 3DS.SET file. <<
I recently tried to go back to rendering a small to medium size (300frame)
*.flc animation on my revised system. I have only 40mb free on the 3DS3.exe
disk, but I thought I had redirected all my swap files to my g:\ drive which
has 2+ gigs free. However, twice I have gotten to approx frame 225 in render
and get a
"Error writing file—not enough space"
message.
When I say that I have redirected my swap files I mean that I used cfig386
-swapdir command to make g:\swap my swap directory, and the 3ds.set file has
been modified to make g:\3dstemp my pharlap temp file location (even though
animation was not complex enough to swap out of RAM).
Is there another file that is paged to disk that I have overlooked? I thought
I had this all down a year ago, but I think I am forgetting something this time
around.
In case it matters, I was using Video Post render with Stars.PXP and
compositing a *.gif and a *.flc under the keyframer geometry. I keep thinking
it was the 40 mb on the 3ds3 disk that is the problem, but I can't remember
anything that needs to be redirected—it was too early for the palette
optimization process, not sure that could be assigned to the g: drive anyway..
I have "last image" save turned off in 3ds.set…
At least the second time I was offered the option of saving the partial flic
file.
Thanks.
Lydell