Mem Use Prob?
2 messages in this thread
Hi Don Hanson / All,
Following up on my Mem Use Prob? messages (#87922, #87986, & #88009) where
I documented the elements in the animation Fish.flc and showed memory useage
under various test situations:
It was my personal judgement that all materials & other maps and the extensive
use of transparency in this anim. were of little consequence w/r/t the total
memory useage. I also felt that even though only <100 Flock particles (71
actual count) were in the test rendered frame, that the *_entire amount
defined_* -> 150 ea. for the master and the two instances = 450 particles =
202,000 faces as defined below……..
((1 master + 2 instances) X 150 particles each)) X 400 faces = 202,000
…..was what was forcing the memory useage so high. In order to test this
theory I created 20 – 10k face spheres, a camera, 3 lights (including the
projector w/ the same bitmap), the fog, and the grad.BG. Rendering parameters
and image size (256×150) were also identical.
The test with the spheres caused the entire 32MB RAM to be used plus a 1.4MB
swap file – very similar numbers to the actual animation use.
To test my theory on the procedural mapping w/ transparency, I recreated the
scene using just the Beige Matte material on the Flock particles, and memory
useage only dropped to 29MB.
Therefore, I must conclude the following:
1) The various Yost IPAS routines as well as the Bubble IPAS routine and
the bitmaps and transparency have little bearing on the total memory
useage.
2) Even though the Flock routine only produced 71 visible particles in
the rendered frame, and only 150 were defined in the master cube and
then instanced twice, the memory results are the same as if all 450
particles were defined in the master object *AND* were all visible
in the frame.
This doesn't sound kosher to me. ANY COMMENTS ?
Regards,
Bill
M.G.
Hmm, I think you missed my point about the 3DStudio imposed limit of 65k faces
per object. Each instance of an AXP'd object is treated as one object, even
though one Flock3D might be drawing more than one "bird". If you have a 1000
face source object, it doesn't matter if you ask for 65 birds, or 500.
3DStudio will only allow 65, so Flock3D cuts the number to 65. This is treated
by Studio as one 65k face object at render time.
About the large memory usage: This is because you're creating such a large
scene. It doesn't really matter if you have 3 flocks at 65k faces each, or if
you have 220,000 static faces in the scene, that's a very large scene for
Studio and you're going to need a ton of memory.
As a test I saved the chevy.3ds that comes with Studio as an .asc file,
(big bad .asc file!) and used it as a source object. Since the chevy contains
more than 32k faces, the maximum number of chevys is one!
(fyi) pages 114-115 in the Installation Guide show the memory usage for
vertices/faces/etc.
I've talked to a number of people who were surprised that a scene containing a
couple of boxes hosting AXPs could bog their 486/586 down.
Most of them had never worked with 150k, 200k+ scenes. There's always some
wild talk about >>improperly designed ipas routines, so please let me explain
Flock3D's memory requirements:
Lets use 65 1000k face&vertex as our example settings.
1) We use two SDK data structures called VData and FData, for vertex and face
data information. This requires us to malloc a structure for each face and
vertex at render time. So 2*65k*sizeof(data structures) – not too bad. This
is required by all axps who wish to use burst mode.
2) We additionally malloc two (somewhat) similar data structures called SVData
and SFData for the faces and vertices contained in the source object.
2*1000k*sizeof(data structures) – this is the "extra" memory we use to let you
pick the shape of the birds.
What about non-burst mode? This would indeed allow us to save memory usage
from #1, but would also run 30-40 times slower. It would also NOT affect the
memory requirements of Studio. (what you're seeing)
What about the new SDK3 for ipas programming? I think the improvements and
new features WILL allow us to save memory from #1, like non-burst mode would,
and should let us go even faster!
(tempting peek: .asc files should go away!)
Clear as mud? 🙂
Don Hanson