Relevant bits quoted below...

I don't see a way offhand that would give you what you're looking for - a lot of what goes on during transition from one app to the other depends a lot on the app receiving the file. If you replace the called original texture with the downsampled one, your renders will reflect that.

For instance, Vue (during import of a Poser file) calls poser.exe and actually uses it to do the translation of the inbound file. Vue can just as easily have poser.exe call the downsampling functions as it can do them itself. IOW, it all rests on Vue's shoulders as to why it eats the memory hit. If you downsample the images during save (or export), then the .cr2 (being a dumb ASCII file with no facilities to call alternate textures) will either churn errors upon re-entry into Poser, or will simply replace the full textures with the downsampled ones.

There are some conceivable methods to get around this. One would be to custom-tailor the exported file from Poser to Vue (or someone else's) specifications (this could possibly be done with a Python script). Problem is - well, three problems:

1. Once it leaves, it doesn't come back, requiring you to have two versions of the same scene saved (a readable-by-Poser version, and the exported version)

2. You're going to need the filespecs for the app you're exporting it to. This means purchasing an SDK, unless the corp is kind enough to publish them.

3. you now have a shiny set of extra textures that you can't do jack with outside of the program that imports it.

Another method would be to rig the export to a common, open format, like .obj and the like. You end up losing dynamics and other neat-o Poser features, but at least you don't have to buy an SDK license, and you can put whatever you like into the .mtl file. I haven't had the chance to peek at COLLADA, but if it has alternates for preview and render texture pointers, you may have better luck with it.

The best method of all would be to build your own format that includes two calls/lines/specs/whatever for each texture: one for the preview texture, and the other for the real texture. Then make sure it's in the file spec so that any corp doing an import can choose between the two.

As for one piece that needs expounding on:

Quote - This might be getting too ambitious, but at the very least you'll need to take the cheats Poser uses into account so you don't get caught offguard...

Heh - you'll have to do that anyway (evil grin). Merchies are notorious for (not always, but still...) including crap mesh artifacts (e.g. a stray edge-less vert or two sitting 10,000 units away from the mesh but doing not much of anything), infintesimally tiny nGons that comprise Lord-only-knows how many half-edges, the occasional horked face normal, bad vert order, little-to-no optimization, bad welds, and a whole host of things that will make life quite jolly for anyone wanting to write software that reads this stuff.

Quote - > Quote -

I think the issue here though is when he transports to Vue or another such application that apparently doesn't automatically downsize for previews, if I read the original posting correctly.

Exactly. Most of the memory issues folks have had with the Vue-Poser workflow have been the 16 megabyte per texture wallop the memory pool takes. The simplest would probably be a 'divide by two' stepping sequence; then you could take a texture down in increments that shouldn't affect the UV mapping. But that only behaves itself when the textures start out in the powers of 2 format to begin with. Oddball sized textures subjected to that can develop noticeable pixellation, or reveal mosaic artifacting at final rendertime, when you subject it to codec compression. And there is no easy way to predict the event happening; its purely a matter of clashing mathmatics. Probably the safest way would be with a divide by two step, a divide by three step, and if the library exists, an option to reduce the color pallete.32 bit textures can be reduced to 16bit, and even 8 bit, depending on the lighting and camera distance. That way you would have a choice of the ways to drop your texture import load without having to deal with another application. Actually, you might want to consider an out and out import conditioning module. Besides texture size, Poser meshes can have issues with backfacing and single sided polygons that Poser either corrects at runtime or ignores....but can bring a mesh import to a sceeching halt with errors. This might be getting too ambitious, but at the very least you'll need to take the cheats Poser uses into account so you don't get caught offguard...