#HEAPMGMT error
9 messages in this thread
The HEAPMGMT error usually indicates that there is a conflict in memory —
primarily TSRs and Device drivers if the memory address indicated by the error
message is in the 640k area, or Disk cache / ram drives if the error message
includes an "EIS" designation.
If this problem doesn't go away with an extremely simple config /autoexec
setup, you might even suspect specific ram chips. (Of course, it's better to
suspect a corrupted program and reinstall 3D Studio.) If it's ram chips, you
can use Phar Lap cfig386 modifications to specify that 3DS use specific memory
locations.
These can be tough errors to resolve. Does your machine have a hardware cache?
If that's the case, try turning it off as well as trying some of the above
suggestions.
Nik
Nik-
After I posted the message, I tried several more tests into the night,
including using version 2.0 instead of 2.01a. Note also I was using four
different machines, involving 3 different caching schemes.
More to the point, I escaped from the render just before I expected it to
crash, and did a status at that point. It showed 62Mb RAM and more than 130Mb
VM used! With some noodling, it became apparent that the scene was using mondo
memory and running out of disk space. We finally got it out by rendering it in
pieces. (Though if this is true, I would have expected a PharLap disk error.)
I killed my message because I was looking for a discussion of how (flat)
automatic reflection maps use memory, which I haven't found. We had a lot of
flat faces each with their own flat auto refl maps. That is what was using
memory, but I'm really surprised it used that much. Can you explain?
–Noah
Noah, each flat reflection map uses a full-screen buffer. Since it's a virtual
mirror of the scene at screen res, they're memory hogs.
– G
G-
That explains a lot. Thanks.
We had been guessing that each flat reflection map would take a bitmap buffer
bounded by the object extents as viewed from the viewport, so that we could get
away with lots of little flat reflective surfaces.
I take it from your answer that each reflective surface holds a screen-sized
buffer only once, correct? Not multiple ones for iterative reflections.
–Noah
BTW, it still seems funny that we get this HEAPMGMT error (which I guess is
yours) and not a straighforward PharLap "out of disk space" error.
Noah,
flat mirrors are *not* iterative, i.e. don't reflect each other. Non-flat can
reflect each other to a certain number of levels.
Martin-
right you are. thanks.
–Noah
Gary,
can I have a prize for using the most flat-mirror's in an animation – 21? <g,d
& r> Animation coming your way soon (next week) on BetaSP…..
Martin "always pushing the limits" Foster
hm… Well, your output resolution was probably something like 50×40 pixels.
<g>
I would be honored to look at some of your recent work, Mr. F. Send it on
over!
– G
Gary,
actually output rez was 512x486x24 bits and field rendered. The worst frames
were taking about 1 hour 10 minutes and the best about 55 mins. I'm glad I
wasn't rendering it on my machine <g>.