I'm thinking that the drive access speed has to do with lots of factors here.

The following is all assumption based on observation:

1. In the preview window, Poser grabs a texture image, but then rinses it through a quick quality reduction before slapping it on the mesh, so as to keep the UI responsive. For instance, say you have a 4000x4000 body texture. Poser would grab that image, but only scan enough of it to get the equivalent of a dirty 512x512 image scale, then applies it according to UV mapping. This explains why you see lots of seams and blurry details in the preview window, but not in the final render. When the render begins, Poser has to re-load each texture from the disk drive at full resolution and re-apply them to the mesh.

Same story for materials, where the preview run may look a bit dirty due to loose low-decimal calculations and reduced resolution image maps behind 'em.

2. I think the mesh gets loaded @ full resolution (it would have to, at least for grouping and other purposes), but during render, it re-reads the base mesh point-for-point, and applies whatever deformation and morphs are present at full resolution (whereas morphs and etc. may be applied to the preview window as a rough estimation before the render.) There may also be a partial bit of smoothing that occurs as well. This means going back and re-reading a lot of mesh and morph info from the disk before calculating.

3. No matter how much RAM you've got, Poser is prolly going to reach into the virtual memory pile during render - a lot. I think it's because physical RAM is more "expensive" than virtual RAM when it comes to storing non-critical and intermediate calculation results, whereas you can write that stuff to virtual RAM and it can be "forgotten" about until needed and retrieved later. This also provides backwards/legacy compatibility for machines that don't have a lot of physical RAM installed (and allows CL to fudge the stated minimum and "preferred" system requirements downwards by a lot more than would otherwise be credible.)

Otherwise, there may be a couple of other small things (for example if there were any Python scripts involved to modify the render itself, that and the Python runtime environment would have to be brought up), but those three biggies up there are my best wagers.

/P

Message edited on: 12/22/2004 11:28

Message edited on: 12/22/2004 11:30