the OS handles all memory aperations at 64 bits, thus improving performance for memory intensive applications. Unfortunately, the memory limit is neverthess compiled into the code of 32 bit applications, and regardless of the underlying OS memory operations, the numbers embedded in the data just basically can't refer to addresses with ranges greater than 2Gb. The next generation always will always, of course be faster and have a better performance for a number of reasons, and quite likely, with a "real" 64 bit bus architecture, data movement will be substantially faster, and page faults reduced, but the 2GB limit won't go away. Its unlikely that any real performance comparisons will directly be relevant to Poser, though. For the vast majority of applications, including those that likely comprise the benchmarks, 2GB is considered to be more than enough memory that any developer needs to implement anything. Even compared with "heavyweight" applications, Poser's memory usage is astronomical. As I've said, DAZ|Studio doen't need to 64bit to achieve greatly more capacity than Poser, all it needs is for the developers to be aware of resource usage and make sensible choices. Interestingly, since DAZ have already sussed out that they needed disk buffering, aka. Morph Injection, to make V3 practical, I suspect that there's a great likelihood that they will be (trivially) automating this in Studio, which by itself will reduce the memory use for figure by a significant factor. Beyond this, if they handle the RSI material capabilities of the 3-Delight renderer according to the book (again with disk storage) the memory requirements for texture maps will effectively disappear. And of course, a Reyes renderer architecture (ignoring Firefly as a bad example) technically only needs one polygon, one pixel and a render bucket stored in memory at one time. If anyone's running a tab, I'd be putting money on Studio having (effortlessly) ten times the "raw figure capacity" than P5. But will OpenGL be able to handle the load?? Bill