Well does it? Because even when reduced in size when I zoom in and render there isn't a loss of quality compared to the same figure at 100%. Any info would be appreciated.

Nope.

bummer:(

If you want to make a difference, reduce the texture sizes.  There are a few myths about the why and wherefore of reducing textures because you will  take a hit in quality if you do it, no matter what you may have heard.

Use a lower poly model if you can get away with it.  Strip out any unused morphs if you can.

V01f and SamTherapy:

I'm glad this subject came up, I had wondered about the size question myself, and I thank you for the information. And, this thread jogged my memory.

At one time there was a script that would export all of the figures/characters/CR2s in a scene, and re-import them as OBJs (props). This had to be done when the scene was ready to be rendered, because the poses and morphs were locked by the process. You could size the OBJs and move them, but you could not change their poses (as I recall). This process would greatly reduce the resources needed to render, and could allow a scene to render that would not otherwise render on older computers/versions of Poser.

Among other things, I think the process did away with ALL the morphs. Unfortunately, I am an endless tinkerer, and never quite finish playing around with poses, settings, placement, morphs etc.. But, one can still play with the materials/shaders of the converted objects after the export/import process. It should go without saying, save your scene/work to a secure file name/directory before playing around like this. It should also be obvious that such a process is not ideal for animation. Even if it was automated it would greatly increase the render time of an animation, and I doubt that it could be done on a render-farm.

I had limited success with this script, and I don't recall the drawbacks for that old script. I don't recall what it was called, who made it, or where it could be found. Considering the advanced programming skills of some of our forum contributors, an updated script for older and newer versions of Poser would really contribute to the community. Myself, I would pay for a script like that for PoserPro 2010.

Of course, with some coaching on the export and import settings, one could do this by hand for each figure in the scene.

lmk

let us know if u remember who made it. Sounds interesting

     For clarification, are you proposing reducing the size (in pixel dimensions) of the preview document window, or reducing the size of the render?

     A large render size will use more RAM than a modestly sized one;  the size of the preview/document window is irrelevant.   My preview window is usually a different size in each "room".

     Some scenes can be split into two or three simpler sub-scenes, usually based on depth (what is in front of what and where shadows fall), and then the separate renders are layered in PhotoShop.  Dolls will generally be the memory hogs, so you would want to divide them amongst the sub-scenes, if feasible.

     Materials can cost a lot of RAM by using certain nodes or combinations thereof.  So,  you might delete unnecessary  reflection, refraction, translucence, anisotropic specular, etc.  Overlapping layers of transparency -common with hair models- really bogs IDL down.  Lots of folks set hair models to be not visible in raytracing because of this.

     Render settings have a great impact on memory load.  Consider how much "bang for the buck" you're getting from each render setting;  some may be costing you a lot -in render time and in RAM usage- for only an insignificant benefit.

Of you mean scaling a figure down, and then zooming in closer to get the same render view then no, it wont save resource. Scaling the textures may give you a slight quality hit, a big quality hit or no noticable change depending on a bunch of factors involving the size, number of pixels in the render, and number of pixels in the texture.

I have not noticed a quality difference between using 3,000 x 3,000 image maps and 2,000 x 2,000 although its half the size.

Quote - Materials can cost a lot of RAM by using certain nodes or combinations thereof.  So,  you might delete unnecessary  reflection, refraction, translucence, anisotropic specular, etc.  Overlapping layers of transparency -common with hair models- really bogs IDL down.  Lots of folks set hair models to be not visible in raytracing because of this.

Each of the nodes you mentioned use less than 100 bytes of RAM. Not 100 mega, or kilo, but just 100. Don't bother. It sounds here like you are talking about saving time, not space. RAM conservation is a matter of saving space, not time.

If you open your Python scripts window and go to Render/IO you'll see at the top a script called Mini-Me.  What this does is export everything in the scene and reimport it at a reduced scale as one .obj.  As a result size is reduced since there are no morphs included for the figure, its clothes, etc.   This is always called yowza.obj by default and is in the main Runtime of Poser.   Everytime it's done it automatically overwrites I believe so it's best to save the prop that is imported in your scene in your library.

I use this for larger scenes usually saving out parts or heavily morphed/clothed figures when I'm fully satisfied with the posing since you won't be able to change that.   Bear in mind that everything in your scene is exported and reimported so be sure to do it gradually as you build up a scene.   Going for one huge .obj would not be advisable.  Most times just doing it for the figures in your scene and turning each one into a complete prop with its clothing, hair and accessories and bringing them back into your scene as simple props can be enough to save you on resources.

As for reducing texture maps I can usually go as low as 50% on most maps, add a bit of sharpening and resave and it makes no difference in the render.   Most maps are overkill anyway for render sizes found in the galleries.   It's only for images designated for print that I would not reduce the map size (especially the skin textures).

I frequently reduce texture sizes when applying them to imported OBJs in Bryce.  I too can reduce a lot of textures by 50%, especially for small or simple objects that don't really need a 4000 X 4000 texture map.  As Kalypso said, skin textures, as well as other intricate texture maps, or maps that are going to be seen close up, probably shouldn't be changed.  Other things you can do to reduce texture overhead in Poser or Bryce are:

1. Substitue materials for texture maps.  Glass, metals, stone, etc. look far better and consume less memory overhead than a picture of glass or a picture of shiny metal.

2.  Bump maps, transparency maps, specularity maps, etc. are almost always color pictures pretending to be black and white (greyscale) images.  Change the mode from RGB to greyscale so that they are truly black and white images and you'll reduce the file size considerably.

1. Photoshop, and I imagine other photo editing programs, also has a "save for web" feature that will reduce a greyscale or RGB image even more without any discernable loss of detail.

I will often make a new "LowRes" folder in a texture's folder and run every texture through the "save for web" function in Photoshop, reduce the resolution of (sometimes every) texture, and convert bump and transparency maps to greyscale.  It's astounding how small the files become.

Reducing texture size had an impact on render memory up until Poser 6. From Poser 7 on, the size and number of textures in a scene is next to irrelevant when it comes to the memory the render engine needs. The OpenGL preview however does depend on texture size, which is why it does the resizing for you on the fly.

Actually on Poser Pro 2010 I had a render hang and then I checked the texture size for a clothing item which was 8000x8000.  By reducing that to 50% I was able to finish my render.   It was the medieval dynamic dress from DAZ and I was suprised to see such a huge texture for what was a fill with just a trim at the bottom!  I could probably have gone even lower to 2000x2000.

What kind of hang? The first time you render an 8k texture in a Poser session, the conversion to a mip map will take a while and the progress bar doesn't move during that time. But that happens only the first time, in all following renders this doesn't happen any more.

Also, do you remember if texture filtering was on or off? Large textures without filtering will be much slower than with filtering (I'm talking about orders of magnitude here), because unfiltered lookups don't work very well with caching.

I'm afraid I don't remember if texture filtering was off or on but I'm sure I got a message that Poser did not have enough memory to render.   First I lowered the bucket size all the way down to 8 and when I still got the message then I checked the texture size.  I will occassionally get the same message in a complicated scene but lowering bucket size does the trick.  

Btw, I'm on Winxp and running the 32-bit PP2010.   Maybe the 64-bit has a better performance since most people on 64 would naturally have more RAM.

What I learned is if you are rendering an item that is closeup from the camera, let the textured be big but if its faraway from the camera, reduce it.

I'm suprised at the size of the texture files mentioned. I think 10001000 is the largest Tx fie I use. Usually 512512 seems satisfactory. I do wear spectacles so maybe I need to get them ckecked.

This was the product I was talking about.  http://www.daz3d.com/i/shop/itemdetails/?item=12004   I could justify maybe up to 4000x4000 for an intricate pattern, but a solid colour fill?  Imagine having 3-4 of these in a scene!   I'd rather use a procedural in this case.

As TheOwl mentioned, unless your scene is a closeup or portrait, there is no need to use such a large texture map.  Of course, texture filtering will determine the resolution of your final render.

@ Kalypso- Now that sounds handy, but a little help please?  Any documentation on the 'Mini-Me' script around?  I keep getting "Import failed - please check the file name."  ** **

Uh... which filename?  Current scene filename is just "test1.pz3" in P6**.  ** 

And, when I do click on the 'Mini-Me' tab in the Python Scripts window, it just takes-off, without any initial dialog boxes.  Is that normal?**
**

**
**

Unfortunately I haven't found any documentation on Mini-Me.  Maybe the python script itself might help you figure it out.   It's in RuntimePythonposerscriptsRenderControlexportImportOBJ.py

I don't think I've ever got that message.  Is it a big scene you're trying to export and import?  Try just a figure first to see if you get the same message.

And yes, my experience since Poser 6 or 7 with this script is that it just takes off and brings in the scene as a scaled down .obj

Hope this helps, I'd be interested to see if you can get it to work.

Working* now!!  

I had not removed the initial 'yowza.obj' (that I'd messed up), and it seems that the existing filename was prohibiting the new files from being written.  (my guess).

*I say "working", but there were some errors with incorrect maps applied to the figure (the bump map was applied as the diffuse map) but nothing that seems not easily fixed.   Pressing onward!

Thanks again for the heads-up on this one.   Sounds like this may enable the ol’whimpy-puter to tackle some more complex scenes, and I’d completely missed it. 

And some stats trivia:
 
-original .PZ3, with a max’d-out, morph-injected V4, a null figure, & 5 other clothing figures, and with 860 animation keyframes, was 197MB,

-the compressed, .PZZ version of the same was 49MB

-the compressed, .PZZ version, with only a single keyframe was 48MB

-after Mini-Me, the .PZZ containing only the resulting combined .OBJ file was 4MB.

Pretty cool.  When I’ve fixed the mapping, I’ll compare the resources loaded & used during rendering.

(bookmarked)

Is there a link to this mini-me script?

Seriously now - has no one ever compiled a list of what all the Python scripts that COME with Poser actually do, or how to use them?

Had Kalypso not mentioned it, I could have clicked and run the 'Mini-Me' script all day long, without ever knowing what it was actually doing, where to find the results, or what on Earth I was even supposed to be looking for!

And frankly, the thought of randomly running scripts to see if I MIGHT be able to tell what they are intended for -- sounds potentially leathal.   (i.e. might one of them be designed to efficiently delete all my libraries??!!)

I don't speak Python, so I fear that just viewing the code in the script would provide very little guidance.

Any of you clever & kind code-writers inclined to give the rest of us a brief overview of what all those suckers are intended for?   Nudge - Nudge!

Almost all of them don't do anything but demonstrate how to do something in Python.

Mini-Me doesn't do anything astounding, except demonstrate how to export a scene as an OBJ file and then import it. The fact that you guys have thought of a reason to do this is totally an accident.

They are there for Python programmers to look at and learn from. To a Python programmer, an example Python script is worth 10 times as much documentation.

Drat - but that makes sense.  Thank-you BB. 

...dreams of hidden treasure dashed   :-(

And, (for those who are even less inclined to be pokin' their fingers into strange places than am I), the python scripts do generally appear to include an initial comment line, not in code, that describes their function to some degree.

I think I've been using Mini-Me since Poser 6.  I like to push all buttons :)