View Single Post
More Comments
Posts: n/a
Red face More Comments - 10-14-2006, 01:15 PM

A couple of more comments since my last guess seemed to be at least partially correct (I do the same thing at casino's, they love me ). I would appreciate any feedback on these!

1. The multiple object issue is (primarily) not one of file size but of the number of calculations (in 3D and with arbitrary angles in Alice) that must be made for each "frame," i.e. each picture update. Without some clever tricks, this goes up as the factorial of the number of objects - which can get big! (4!=24, 8! is >40K, 12!=5E+8, 16!=2E+13)

Needless to say, nearly all movement calculation methods use compression algorithms that do rough, multiple frame calculations and don't update things that don't appear to move. (Doesn't always work well - look at fast moving pictures on your cell phone.) Gabe mentioned using copies (good hint, I didn't know that ); also try "move to" commands rather than incremental moves. (Question for Gabe to ask the developers - does making an object "not seen" also remove it from the position calculations? At first glance this doesn't seem to help.)

2. Usually (NOT always) it's not the total file size that is really critical - but the size of the individual files, which determine the number of times one must go to secondary (slow) memory. (I'm told, and have no reason to doubt, that Alice (and Java) also have a memory "leak" problem although I'm not completely sure what that means. Something about the "destructor" not working right - or maybe that was Star Wars. )

Finally, based on experience (going back to Mariner images), the problem will never be "fixed." No matter what the hardware and software guys do, the customer/user will always want better resolution, higher quality images and more accurate motion. It's sure more fun being a user.

Reply With Quote