#Memory puzzler?
11 messages in this thread
I observed recently while running many test renderings to fli that memory used
went from 10660 swap 0 to 31072 swap 9172 during the keyframing adjustment
sessions. The first frame time rendering went from 48 seconds 105 seconds. I
saved the last prj file and took a break then came back to finish up the
testing. I rebooted 3ds and loaded my last saved prj file, the one that
swapped and took 105 seconds to render the first frame. Surprize! It now only
takes 47 seconds and 10440 memory, similar to the first test I did.
What's going here? Does 3DS tie up memory and not release for certain
operations? Why does the same frame take progressively longer to render and
restarting 3DS speeds things up again? Do we need to reboot every so often to
make things run faster?
Don,
As it says on pp. 70 of the Installation and Performance Guide, once 3DS starts
to page to memory during a render, it continues to use that swap file for
subsequent renderings. The only way to stop the paging is to reboot the
program.
Hope this helps,
-Alan Iglesias
Thanks Alan, but page 70 still doesn't explain why a 10 meg mem requirement
file even started to page to the swap disk with 31 meg ram available. Could it
be the test rendering to the fli file chewed up the extra mem.? A second
thanks for the page 70 reading assignment because I learned that I can get rid
of those zero byte files from my C: root. I'm going to set the cfig.386 to a
stacker drive. I really should read more of these manuals. You see, I had a
friend spend a weekend teaching me 3DS fundamentals so I never went through the
Tutorial. I find I'm severly lacking in certain areas of this package.
I'm probably not an objective observer, but you would have learned more by
spending the weekend going through the tutorials. <g>
– Jack
Jack:
I won't tell what you said. He thinks quite highly of his ability with 3DS and
Autocad. <g>
Alan is right but I think this is something else. If I understood correctly, it
should never reach the point of needing to swap out to disk. Memory did get
used and unreleased and then 3DS started to swap. I've seen that problem before
and I'm blaming Watcom (C compiler) for that.
This is a shot in the dark, but if you are using a Targa+ with the driver
suplied by Truevision (compiled with Watcom), try using the driver that came
with 3DS (compiled with MetaWare).
If that's not case, I dunno what else!
Gus (at war in Waterloo) Grubba
Gus:
>> Gus (at war in Waterloo) Grubba
Remember what happened to Napolean there! <g>
>> Remember what happened to Napolean there! <g>
Well, between Wellington, Blucher, Nixon and Napoleon (I guess one of them was
different waters), I have my soup closer to Coventry than to Paris…
(Sir) Gus
The RDPADI is set to RDPTPLUS.exp and RCPADI is set to RCPVESA.exp. Main
display is set to VGA and Materials set to RCPADI. Rendering is RDPADI.
Couldn't tell you what compiler was used for these drivers.
The RDPTPLUS.EXP driver is the good one. That's the one included in 3DS and
compiled with MetaWare. This blows off my theory. Are you using some IPAS
routine?
The gremlin is gone! I can't duplicate the problem now. Of course the prj file
is fully developed so who knows what I was doing at the time that caused the
memory requirement growth. I guess I should'nt worry about it because if it
ever happens again I can just exit out and restart 3DS to prevent paging.
Definitly no IPAS and I was not tessalating objects either.