#memory hungry mat editor
10 messages in this thread
Gary,
I seem to remember hearing of a problem someone was having a while back
with the materials editor swiping memory from the renderer. I can't quite
remember, but regardless, I'm having that problem now. I just noticed the
problem on a large mesh I'm working on, but did some tests on several different
files and wound up with the same results to varying degrees.
Here's a simple example: I start up 3ds, load my mesh file, enter the
mat editor and load the single material from the scene, then go straight back
to the 3d editor and render a view. Memory for the render on this mesh is
27,236k (scene has 16k verts, 32k faces, 2 omni lights, one bumpmap material w/
a 250k bitmap, and rendered with no background at 512×486, phong, AA on – does
the mem usage sound about right for this?). I then go back to the mat editor
and simply change a setting and render the sample, then go back to the 3d
editor and rerender the same viewport. This time it uses 37,196k and swaps
3,520k. That's a 13 meg difference for simply changing the shininess!!
I think r3 has been doing this all along, but I haven't noticed because
this is the first scene I've done in r3 that has swaped. I still need to narrow
down the details of when it happens and when it doesn't and fiddle with my
configuration a bit to see if it goes away, but do you have any thoughts in the
meantime of what this could be? Has anyone else run into this kind of problem
before?
Thanx,
David
David,
What kind of configuration do you have? Specificly, are you using any ADI
drivers? Other drivers for your video board? Device+ drivers for SCSI cards or
whatever in your config.sys?etc.
-Brian
I think the problem is probably with your hardware, David. I just spent 30
minutes thoroughly testing this on my system. Here's what I did:
1. Loaded attic.3ds and render 1x. Memory usage was 13996.
2. Went to medit and loaded Chrome Gifmap from the attic scene.
Memory usage was 14056.
3. Went back to editor and rendered 1x. Memory usage was 15024.
(Note that this jump of 1Mb is due to Phar Lap's needing to
allocate another 100K at this time, but it was on a PL memory
boundary, so PL allocated a full 1Mb. This is normal, and after
this it will stay stable.)
4. Went back to medit and changed the shininess in the Chrome Gifmap
material. Rendered the sample sphere. Memory usage was 15084.
5. Went back to editor and re-rendered viewport. Memory usage was 15024,
actually lower than the last time I was in Medit.
6. Just to be sure, I went back to medit, changed shininess again,
and then did a Render Last from medit. Memory usage was 15084,
the same that it was the last time I was in medit.
7. Again, to be sure, I went back to the editor and rendered again.
Memory usage was still 15024.
Finally, just to be absolutely positive, I went through steps 6 & 7 four more
times. No change.
What kind of motherboard, bios, and memory manager are you using?
– G
I tried the attic scene and didn't have a problem. Try this to see what
you get.
1. restart 3ds.
2. load monster.3ds from the clipanim directory on the cd and render the front
view. (I set AA off, BG tile, everything else default to a Targa at 512×486.
Mem usage = 12356.
3. enter mat edit and load "chrome tutorial" from the scene.
4. go back to 3d edit and render last. Mem usage = 12420.
5. go to mat edit and change shininess and strength to 100, then render the
sample. (I'm willing to bet I'd get the same results if I left all the settings
as is and just rerendered the sample, but I didn't try)
6. go to 3d edit and render last. mem usage = 14560
From that point on it will stay steady, but is it normal for the mat
edit to tie up memory it needs for it's renders (I'm guessing that's where the
2 megs went)? The reason my file was losing 13 megs is because the map was
quite large in resolution, even though it's only 250k in size.
My system is a gateway dx2/66, micronics vlb mb (pheonix bios), w/
targa+, Herc chrome video (but 3ds is running off of an ATI vlb using the
inline vesa drivers), a future domain scsi card w/ 1 hd and a cd-rom, an ide
drive controlled on the mb( 3ds runs on the scsi drive), a wacom tablet,
and 40 megs ram managed by qemm 7. The only adi device running is the targa, I
believe. oh yeah, and dos 6.2.
And here's my config.sys and autoexec (or portions of…) for Brian R
at adesk:
[studio]
DEVICE=C:\QEMM\DOSDATA.SYS
set loadhidata=C:\QEMM\LOADHI.RF
DEVICE=C:\QEMM\QEMM386.SYS RAM ROM=C000-C7FF rom=f000-ffff… …X=A000-C000
X=D000-DFFF RF
DEVICE=C:\QEMM\DOS-UP.SYS @C:\QEMM\DOS-UP.DAT
SWAPFILE=DPMI.SWP SWAPSIZE=1024
DOS=HIGH,UMB
SHELL=C:\QEMM\LOADHI.COM /RF COMMAND.COM /E:1024 /P
STACKS=9,256
FILES=50
BUFFERS=10,0
DEVICE=C:\DEV\FDCD.SYS /D:MSCD000
LASTDRIVE =G
DEVICE=C:\QEMM\LOADHI.SYS /RF C:\TPLUS\TARGAP.SYS MD D6 I230
DEVICE=c:\qemm\loadhi.sys /RF C:\DOS\ansi.sys
—————
:studio
C:\QEMM\LOADHI /RF WMOUSE
c:\qemm\loadhi /RF C:\DOS\mode lpt1:,,b
c:\qemm\loadhi /RF vvesa
c:\qemm\loadhi /RF C:\DOS\MSCDEX /D:MSCD000 /M:10 /E /L:F
TMODE 11
tpclr
prompt $e[1;31m$p$g$e[0m
set tiga=-lC:\TIGA -mC:\TIGA -i0x60
c:\qemm\loadhi /RF tigacd
goto end
Let me know what your memory usages are, meanwhile, I going to drop the
size of the map in my problem file and get back to work.
Thanks again,
David
To put your mind at rest, here's how that worked on my system:
2. load monster.3ds from the clipanim directory on the cd and render the front
view. (I set AA off, BG tile, everything else default to a Targa at 512×486.
Mem usage = 12356.
GY: I get 12248 here. Almost the same thing.
3. enter mat edit and load "chrome tutorial" from the scene.
GY: Here's where you will eat up about 2Mb if you even render a
sample sphere. You've loaded a material with two 1024×768
texture maps assigned (rock4.gif and ground6.gif). Lots of
RAM gets allocated here. But note that it'll NEVER get
reallocated. (We worked very hard on this part of the code,
and it works perfectly.)
There ya go,
– G
Gary,
>>To put your mind at rest, here's how that worked on my system:
>>3. enter mat edit and load "chrome tutorial" from the scene.
GY: Here's where you will eat up about 2Mb if you even render a
sample sphere. You've loaded a material with two 1024×768
texture maps assigned (rock4.gif and ground6.gif). Lots of
RAM gets allocated here. But note that it'll NEVER get
reallocated. (We worked very hard on this part of the code,
and it works perfectly.)
Well, my minds not at rest, I'm still confused. Are you saying that when you
render something in the mat editor, it will allocate the memory it needs for
the maps, and then that memory is no longer usable by the main renderer at all
until you restart the program? How come the material is loaded and renders on
the screen, but no memory is taken until the sphere is rendered a second time?
Is there a way to unload a material from the editor and free the memory that
the materials renderer has allocated as its own. (I personally think the mat
editor's being a little selfish here, don't you?)
Could you go into a little detail on how the memory is allocated in
this situation? I read the memory section in the install guide, and while being
enlightened on how much mem is really needed for maps, I don't think it says
anything about the materials renderer needing its own block of memory in
addition to the main renderer's.
David
Basically, what's happening is that the memory is getting allocated in Medit,
but the fact that it _was_ allocated isn't showing up until you've gone back to
the main renderer. Just the way it is in Phar Lap land.
– G
Ah yes, Phar lap land!
>> the memory is getting allocated in Medit, but the fact that it _was_
allocated isn't showing up until you've gone back to the main renderer.
Sorry to be dragging this on, but when I enter the scene and render it,
3ds uses x memory. I then go to the medit and load the material, it renders
automatically to the screen (shouldn't the xtra memory be allocated at this
point?) then I go back and rerender the scene, but memory usage is only a
little higher than the first time. So even with a material loaded, the renderer
seems to have almost all the memory available to it. I then go back to the
medit and rerender the material (this seems to be when the memory is actually
allocated, on the SECOND material render). It is only at this point that the
main renderer looses the memory.
I'm sure 3ds is doing what it's supposed to do in this case, but I'm
just wondering why the medit can load a material and still share it with the
renderer, and only on the second material render is it allocated for itself. If
it IS allocated when the material loads, then the memory usage reported from
the second scene render is not accurate.
And yes, I do realize the answer is probably going to be "that's just
the way it works."
Just curious,
David
>>And yes, I do realize the answer is probably going to be "that's >>just the
way it works."
That's just the way it works.
– G
Thanks. I'm using scaled down copies of the maps in all but the final renders
now, so it's not a problem anymore.
David