#Mem Use Prob?
13 messages in this thread
>> Ah ha… It certainly _could_ be that an improperly-programmed IPAS routine
would allocate all available memory. [Gary Y.]
>> I've used both of those IPAS' (flock, digim. bubbles) frequently, and have
never run into swapping other than predicteably "swappy" stuff (lots of BIIIIG
texture maps). [John T.]
Okay – Gary, John, et all: Let me try something before hitting Jonas with this
one. You know I'm relatively new with 3DS – but – I've used *many* app's for a
long time. There are some unknowns to me regarding the elements of this anim.
though, such as the flock.axp allowing mapped, user-defined particles and how
that affects memory use – or the bubble.axp for that matter, *_once the
procedurally/user-defined objects are generated_*. Or *exactly* how instances
of procedural routines are handled (if any difference at all).Therefore, let me
break down the elements as they relate to this puzzling situation – you tell me
if it sounds unusually "steep" to you:
BREAKDOWN OF PROGRAM PARAMETERS FOR FISH.ZIP
============================================ After Program
Boot: Avail. Mem. = 31,500 Mem. Used = 2,880 After Loading
.3DS: Mem. Used = 3,832 After 256×150
Render w/ ALL .axps OFF (no a/a,shad.,m/b): Mem. Used = 8,404 After Above w/
Bubble.axp ON: Mem. Used = 8,452 After Above w/
Flock.axp *Master Object* ON: Mem. Used = 18,088 After Above w/
2 Additional Flock Instances: Mem. Used = 31,484
Swap Used = 408
After Above at 756x486x24 w/ A/A ON: Mem. Used = 31,484
(????) Swap Used = >12MB
PERTINENT ANIM. INFO
====================
7 Objects – 11,243 Vertices – 21,900 Faces – 3 Lights – BG Grad. – Fog – Gamma
No Fields – Dither T/C & 256 – Pixel Size 1.5 – Med. Flic Pall. – Targa No Alph
IN 3DS.SET: Render-Band-Height = 80
A substantial amount of the face count is in the copy of the dolphin used in a
2 object morph cycle. (which of course only 1 appears in render)
1- Bubble_I w/ 550 bubbles (<100/frame) – 8 face Particle.
1- Flock3d v.1.0a w/ 150 Particles (<100/frame) – 408 face Particle.
2- *Instances* of above. (still <100/frame).
1- .CEL bitmap at 55.5k —- 1- .BMP bitmap (proj. light) at 163.6k.
MATERIALS INFO
==============
#1) Using Dents_I.sxp, 8 iterations, mapped to 8192 face reef object.
#2) Just Color
#3) 2-sided w/Transp. using CCUBE_I.sxp & NOISE_I.sxp mapped to FLOCK particles
#4) Just Color
#5) 2-sided w/Transp. using WATER_I.sxp as TEXT.,OPAC.,& BUMP – 3D Dist..
Planar-mapped 1×1 to 200 face 2-D grid object.
#6) 2-sided w/Transp. using Noise_I.sxp for TEXT., and the .CEL bitmap for
OPAC. & SPECULAR – mapped to BUBBLE particles.
I believe that about covers it. I don't know guys, what do you think ?
BILL
Your flock.axp dude is definitely eating up a humongous chunk of memory. This
isn't, however, a "IPASFIX" type problem. Were that the problem, it would have
eaten "all" memory right in the first instance. The flock procedure is probably
allocating some major buffers for doing something. Who wrote that thing any
way? Isn't he around here?
Thanks for the info Gus….sure seemed odd to me. This is a routine from
BLACKBOX a/k/a NW TECH SYSTEMS a/k/a Dr. Pixel (?). They also did the Vortex &
DFilter routines and posted demo's here. Thanks for your time in responding.
I'm uploading the document again, as it seems to have gotten scrambled
(although you obviously could read some of it).
Regards,
Bill
Gus,
<< who wrote that thing..>>
Jim Galasyn & Don Hanson….and Don's around all of the time.
jonas[adesk]
That's what I thought. Isn't he following this thread? Ask him to check his
mallocs and also to check if he's got some "abnormal" stack allocation at link
time.
M.G.,
Been doing the hardcore programming thing for the past couple of days.
I'm checking over your messages now and will post you again tonight.
Don
Thanks, Don. I'm very curious.
M.G.
I'm using DOS CIM, so I can't get a message via a #, and my set message date
won't go back far enough, so… I'm not sure what the question here is. 🙂
Are you able to assign an SXP as a material to a flock'd object?
Early tests showed us that only one IPAS program could run on an object. If
you could once again repeat your questions for me…
About the memory usage: Since AXP objects only exist at the time of rendering,
the actual face count never appears. The real face count for Flock3D is the
number of source object faces * the number of "birds", (w/ a 3DStudio limit of
65,000 faces per object).
65,000 divided by 408 faces per dolphin means a maximum of about 159 dolphins
per Flock3D instance. Flock3D will automatically turn down the number of
"birds" (or dolphines) to stay under this limit.
Rambling on just a bit here: One flock'd object and two instances would be 3 *
65,000 faces, plus 550 bubles * 8 faces per particle, plus the visable 21900
faces contained in the rest of the scene, or just a bit over 221,000 faces at
render time. So I think you begin to see exactly where the memory usage is
comming from.
To dramaticize this, set the Flock3D (& instances) to 160 "birds",
then sub in diamond.asc for the source object filename. This should give you
dramatically faster rendering times. Though I'm sure it won't look nearly as
good 🙂
I've already got a check on the suggestion list for a small field near the
'number of "birds" slider which will show the actual face count at render time.
Your scene sounds very interesting, will we get to see it?
Don Hanson
BlackBox
Thanks. Will zip up entire summation & send E-Mail. Please see mssg. # 88377.
M.G.
Whoops, I think our message interaction timing got messed up there.
Just got your >>zip up entire summation message.
I've got to get the Windows version of CIM – I'm told it can access mail by
message number. My poor old DOS CIM won't do that. 🙁
Standing by,
Don
Hi Don. I've been using Flock with an even greater number of particles than
Bill, but haven't experienced any major memory hogging. Then again, I don't
have any .sxp's assigned to the .axp particles.
John Tissavary (La Luna cie)
I'm lousy at math, so I didn't add it all up, but you're using a lot of
procedural stuff… it FEELS <g> like you could go over the limit on a 756×486
rendering.
What I usually do is render the .axp's seperate from the rest of the scene with
alpha on (unless the edges are very blurry), then composite that with the scene
in VP. This also allows me to re-render the .axp's without having to do it ALL
over again, and saves memory throughout the whole process. I imagine that with
the transparencies and .sxp's, which definitely suck memory, you could still
come out ok as long as you render the flocks and bubbles seperately for VP
comp.
Just a thought,
John Tissavary (La Luna cie)
That's all I ever did with 3DS before recently (render IPAS stuff w/ Alpha on
and take out to other programs to composite). With R3, the rendering and so
many other things were improved so much, I've started *trying* to use it more
*exclusively*. I don't know if this particular project could be layered for
several reasons I'll get back to you on (ON-LINE now). Thanks for the input.
Bill