I'm just curious as to how many people out there actually do this. For the textures I use most often I have usually three different resolution variations. One for high res images (usually portrait) a med res (for full body images), and then lo res.

And even then I very rarely use a 4000x4000 res texture. The highest I usually go is 3000x3000. 
For most images you can't see a noticable difference.  I know some like to render large res images for easier postwork and that somewhat makes sense.

Another thing I have found that is misleading is poly count slowing things down. It does to a degree but for the most part its the texture resolution that eats up your memory.  
For about 50,000 polys you use somewhere in the range of 10mb of memory. For a 1500x1500 texture your eating up around 25mb of memory. 
For raytracing the higher poly count will slow down rendering because of all the angles to calculate the light being bounced off of. But the initial load is all on the textures.
With hair you will find that if you go to object properties and turn off seen by raytracing it will significantly speed things up.

Then there is the relationship of "slowing down" and memory usage. By slowing down I dont just mean render times, but how responsive the program is as well. In P6 if I have high res images loaded it becomes almost unusable at times. (click and wait, click and wait).  So If I use lower res images then the rendertimes may not change a lot but things are much easier to manage and poser isnt having to write to disk for memory constantly. 

anyway just curious what others think on this topic.

Textures should not be 3000 x 3000, they ought to be powers of 2:  512 x 512, 1024 x 1024, 2048 x 2048, 4096 x 4096.

@muralist: Any reason why?

Quote - Textures should not be 3000 x 3000, they ought to be powers of 2:  512 x 512, 1024 x 1024, 2048 x 2048, 4096 x 4096.

yeah i know thats what they ought to be but give me some proof of the differences between using 2000x2000 as opposed to 2048x2048.

Its the same as resizing images in photoshop. You will get better results with less pixelation going by powers of two.  But as for rendering I have found no noticable difference in render times or the way it looks.

I don’t' have a real visual or snazzy math proof handy, but I do know that images that follow powers of 2 resize in a cleaner manner because they have less chance of introducing artifacts due to rounding errors in interpolations.

You can run a little experiment in Photoshop, take an image of perhaps 512x512 with a bit of crisp detail. interpolate it to various sizes. Try 256, try 1024 or 2048. Then try 200, 500, 1000 or 2000.  As you examine each, you'll notice that the images sized at powers of 2 will have slightly less amount of artifacts due to resizing.
It can be especially handy if there are filters that will be applied to the image.

As images can be resized several times, during texturing, image loading, then rendering, it's just one of the little things that will improve the quality a little bit.

It won't be make it or break it kind of a thing, but it falls into the 'every little bit helps' kind of a category.

It has to do with the way the algorithm for resizing images works.
 "every little bit helps" is so true.
 But the point I'm trying to get at is that people are rendering characters or props that look to be 100 yards away from the camera and still using 4000x4000 + textures. Then wondering why it took 4 hrs to render or they simply couldnt get everything in the scene to load. Cut corners where you can, in most cases if you do it right then its not even noticable. 

Quote -  But the point I'm trying to get at is that people are rendering characters or props that look to be 100 yards away from the camera and still using 4000x4000 + textures. Then wondering why it took 4 hrs to render or they simply couldnt get everything in the scene to load. Cut corners where you can, in most cases if you do it right then its not even noticable. 

Very good point!!!   Texture size should be appropriate for the size of the object in the scene to be textured. If the object in the scene will only cover, let's say 300x300 pixels, there's no need for a 4000x4000 image.

Actually something I'm planing on doing with the thing I'm making right now is providing two sets of textures. Hi rez for closeups and lo rez for far away shots.

The image quality detail that I was mentioning earlier only applies for closeups. I sort of assumed since the image resolution and quality was mentioned, we're talking about closeups where it may matter.

I agree with you there, onnetz, discussing or worrying about texture artifacts and image quality for a something tiny would be rather moot :)

Somthing else I didn't mention is that while poser gives the option of texture size in render settings those full size textures are still getting moved around in memory. Whereas if you resize the images yourself then only that gets tossed around in memory.

Well there are times when you need "every little bit" and using powers of two is one way to add to it.  So I'm actually glad that was brought up.

I guess it all comes down to how much effort you want to put into an image. The initial resizing of images can be a pain with having to redo shaders as well, but once done it is worth it.

Another thing I'm a firm believer of is that if its not in the cameras view then it really doesnt need to be there.  If i'm doing a portrait of a face closeup then anything below the neck is a waste. I've setup a v4 character thats nothing but the shoulders on up.. everything else has been removed.
Works great.. :-)

The camera view and removing the extra details is a very good point :)
Something lot of higher end applications have resolved with viewport clipping :)  (Don't ask me details on how that one works, I just know it exists in a few that I have or have tried)

Viewpoint clipping is great along with backface culling. Only problem with them is that they dont really come into play until render time. (not entirely true but close)
You still get that initial overhead of loading everything in the scene.

If I give you a perfect texture at 1000 x 1000, you should not slavishly resize it to 1024 or 512. You will introduce artifacts.

It boils down to keeping an integer multiple (or fraction) of the original number pixels - this minimizes artifacts. If I give you 2048 and you want to shrink it, by all means use 1024, not 1000. But if I give you 2000, shrink it to 1000, not 1024.

Bingo, Bagginsbill :)

"Power of 2" is a rule from times we worked with 8-bit processors.

the joy of bitwise operators.

What is a reasonable workflow for using textures with lower resolution. In Poser 6 (or was it Poser 5) I could set Max Texture resolution but I don't see how to do this in Poser 7. The geometry and textures are all in my main runtime... poser can't reliably find them otherwise even with "deep" search... should I copy Matposes and their textures to a new "lo-res" runtime and then re-sample all the textures in that runtime and set the poses to absolute paths? What app can go through sub-directories shrinking textures down so I don't have to go through them one by one? I guess IrFanView can do one sub-directory at a time which is good enough.

I wish that the damn figures were built with geometry swapping so I could load a low res body in for partially covering clothes or a low res head in for a distance figure! I can't belive they never released Reduced Resolution SP3 or David... and the EF Miki and EF figures have riduculous mesh density for figures that don't really morph. I can barely run them.

"*If I give you a perfect texture at 1000 x 1000, you should not slavishly resize it to 1024 or 512. You will introduce artifacts.

It boils down to keeping an integer multiple (or fraction) of the original number pixels - this minimizes artifacts. If I give you 2048 and you want to shrink it, by all means use 1024, not 1000. But if I give you 2000, shrink it to 1000, not 1024.* "

I totally agree, except for one small (rare) caveat...

If the original texture is just over one of the magic (512, 1024, 2048 etc.) numbers square (A silly example: a texture that is originally 1100x1100) then there is a very good case for shrinking it down to 1024x1024, unless you really need the detail.

And that reason is that when textures are in memory they are padded out to one of those "magic" numbers ('cos that's the way that computers work). So that 1100x1100 texture actually gets padded out  the next highest "magic" number in memory, in this case to 2048x2048 . No extra detail is added - the extra padding is just "wasted" memory (898,704 bytes of it). The texture still is only 1100x1100, but takes up 2048x2048 bytes. All of those extra bytes just sit around, being moved and manipulated and preventing anything else from using that space.

So, as with everything, think ahead before deciding on texture size...

Cheers,
Diolma

As for the mat poses thats what I meant by redoing the shaders.. 
I have texture and pose folders for different resolutions.

The program I use to resize images is called fotosizer. 
http://www.fotosizer.com/
works great and I've never had a problem with it. 

As for the geometry yeah its a bit of hand carving to get what you want. 
You can export just the parts you want as .obj and then import as a prop.
Take it into the setup room and use the existing rig from the original figure and let poser do
its automatic setup. Then save it as your low res figure.

What I wish is that poser made use of normal maps. Its a great way to get a high res looking model with very little geometry.

A program is in the works to simplify this whole process.

8 bit we once used, 64 bit now, but still powers of 2...;)

thanx

I'm glad this thread came up because I didn't want to start a Poser 8 wish-list thread. What would really be cool (though I don't expect to see this happen anytime soon) is if Poser used some sort of mip-mapping; converting texture sizes based on camera distance. A (power of 2) pixel texture size from one ^ 2 to (say, arbitrarily chosen value of) 2048 ^ 2 are all stored on the same map, whose proper resolution is loaded into memory on demand, which reduces (texture) memory footprint from (arbitrarily chosen value of) 250MB to 10MB. IMHO this is why Poser is occassionally instable, especially throwing 25 copies of 4K ^ 2 textures at it. Does one really need this resolution if they are NOT rendering for the silver screen? Though I don't know the inner workings of Firefly, most rendering engines will resize textures to the next lower power of 2 size, so using 4000 pixels is a waste since it will get resized to 2048. [Edit - I think Dioloma is correcct and that it will get resized up] Will most people notice the difference? No. Will fine details get lost? No, because chances are you won't see them anyway. Finally, there is a specific reason why you'd want textures to be powers of 2, but I don't remember off the top of my head. I'll see if I can find it. [Edit - I don't remeber where I read this, though I'm still looking and this explanation is decided non-technical. A non-power of two texture is resized up to the next power of two size. The area with "missing" information is filled with color = 0,0,0. This increases the memory footprint but contributes nothing to the image. Translation: wasted CPU cycles.] [Edit - cross post. Very embarrassed]

Quote - "*If I give you a perfect texture at 1000 x 1000, you should not slavishly resize it to 1024 or 512. You will introduce artifacts.

It boils down to keeping an integer multiple (or fraction) of the original number pixels - this minimizes artifacts. If I give you 2048 and you want to shrink it, by all means use 1024, not 1000. But if I give you 2000, shrink it to 1000, not 1024.* "

I totally agree, except for one small (rare) caveat...

If the original texture is just over one of the magic (512, 1024, 2048 etc.) numbers square (A silly example: a texture that is originally 1100x1100) then there is a very good case for shrinking it down to 1024x1024, unless you really need the detail.

And that reason is that when textures are in memory they are padded out to one of those "magic" numbers ('cos that's the way that computers work). So that 1100x1100 texture actually gets padded out  the next highest "magic" number in memory, in this case to 2048x2048 . No extra detail is added - the extra padding is just "wasted" memory (898,704 bytes of it). The texture still is only 1100x1100, but takes up 2048x2048 bytes. All of those extra bytes just sit around, being moved and manipulated and preventing anything else from using that space.

So, as with everything, think ahead before deciding on texture size...

Cheers,
Diolma

I dont agree. I can write a program that will keep any size texture in memory that I want it too. The computer itself doesnt care what size the texture is. Poser itself might do this but it has nothing to do with the way computers work.

Quote -
Edit - I don't remeber where I read this, though I'm still looking and this explanation is decided non-technical. A non-power of two texture is resized up to the next power of two size. The area with "missing" information is filled with color = 0,0,0. This increases the memory footprint but contributes nothing to the image. Translation: wasted CPU cycles.]

Again, maybe poser does this and I dont see any reason why it would but as per all programs it simply isnt true.

Image data is generally loaded into an array of width and height.. So saying you need an image of the same size and width or even a power of two is just silly.

For P6 but specific to this topic.
http://www.e-frontier.com/go/p6tutorial2

Quote: Image data is generally loaded into an array of width and height.. So saying you need an image of the same size and width or even a power of two is just silly. Maybe. But why is that integer types, floats and double number types in C have minimum and maximum values that are (gasp) powers of two? I invite you to peruse http://en.wikipedia.org/wiki/Power_of_2, paying special attention to the second paragraph of the section titled: Fast algorithm to find the next-highest power of two to a number in the ring of integers modulo a fixed power of two . Sure, you don't NEED textures that are powers of 2, but they appear to be more efficient. And why would I want to do anything that makes Poser run less efficiently? Just my opinion.

how is using an array of 1024x1024 more efficient than an array or 1000x1000?

each pixel is stored in  8, 16, 32 or 64 bits depending on what data type you use.  For each pixel your storing rgb data and in some cases alpha, brightness and luminosity values for each pixel. . all of these can be stored in a different data type.  So in the end the width and height value of an image is really irrelevant.  When it does become relevant is when you perform an algorithm on the image, like resizing it.  I'm sure you could write an algorithm that would resize images better that weren't to the power of two.

to the computer 1024 is just a number.. the same as 3 or 7.

@onnetz: You know, perhaps I'm seeing what I want to see. Especially in relation to UV mapping, several people suggest to use powers of two, though I grant you that textures CAN be rectangular - and are made more efficient by being powers of two because they are faster to access. I'm not sure if you're playing devil's advocate or if you seriously believe that a 537*723 is more or less memory drain than a 512^2 texture. I hope the former is true. For mental ray AND Renderman which both efficiently cache textures, you would convert your textures to mip-maps (the application specific names are different). The documentation for both of these production quality render engines RECOMMEND that you output should be power of two; the resulting mip-map WILL be square. Since Firefly is Renderman-compliant, then it stands to reason that Poser could benefit from the same texture treatment. I say this with the greatest respect and humility, but I'll rescind everything I've said if you can produce a compelling argument that would dissuade me from the advice of software engineers and programmers. I would be happy to provide you with ISBN numbers to support my view.

Using 2^n sized textures is very very important for real time. You won't see a real time texture that is anything other than 128x128, 256x256, and so on. It obviously is not irrelevant to real time rendering; else there would not be such a huge importance attached, and universal adherance, to the rule.
I don't know how much bearing it would have on software rendering.

Quote - ...What I wish is that poser made use of normal maps. Its a great way to get a high res looking model with very little geometry...

According to Stonemason, you can use normal maps already in the gradient bump. Haven't tried it myself; but have no doubt that he knows what he's talking about.

a 537723 image will need more memory allocated than an image that is 512512.
if you process every pixel of data then how can it not?
allocate 8 bits per pixel..
5377238 = 3106008
5125128 = 2097152

If your talking about a program using mipmaps then it may round to the power of two. opengl has gl_nearest and gl_linear Maybe thats what poser does, I dont know and actually stated that earlier.

Quote - Using 2^n sized textures is very very important for real time. You won't see a real time texture that is anything other than 128x128, 256x256, and so on. It obviously is not irrelevant to real time rendering; else there would not be such a huge importance attached, and universal adherance, to the rule.
I don't know how much bearing it would have on software rendering.

---

Quote - ...What I wish is that poser made use of normal maps. Its a great way to get a high res looking model with very little geometry...

According to Stonemason, you can use normal maps already in the gradient bump. Haven't tried it myself; but have no doubt that he knows what he's talking about.

yeah in realtime rendering your programming is video card specific. 
totally different in software rendering. Posers preview would like images that way I'm sure.

as for the normal maps I remember hearing somthing about that from bb..... never looked into it but I may in the near future.

Found what I was looking for in the Renderman documentation (all rights reserved), though it applies to Poser only peripherally since it doesn't have mip-map capabilities: "Textures are indexed using (s,t) coordinates ranging from 0 to 1. Note that the coordinates of a texture map are like the coordinates of a raster image: the pixel with texture coordinates (0,0) is at the upper left corner of the image. The s coordinate increases to the right and the t coordinate increases from top to bottom. For reasons internal to the texture mapping software, texture files must be an even power of two in width and height. Any input image which is not already a power of two in both dimensions will be resized, as described below. For shadow textures, the resolution of the texture file is derived from the height and width of the image file, each rounded up to the next larger power of two. For example, a 256×512 image file will generate a 256×512 texture, while a 250×84 image file will generate a 256×128 texture. Additional black (zero) pixels are added to the picture data as necessary to fill the texture file. The shadow operation may be incorrect for input images that are not sized to powers of two. For simple textures or environment textures the resolution of the texture file is determined from the height and width of the image file and the operation specified by the -resize option. If either the width or the height of the image is an exact power of two, that dimension is left unchanged. Any dimension that is not an exact power of two will be adjusted according to the -resize operation. The resize operation may be one of: [the following options, which I have omitted] The default resize operation is up. When texture access corrects for the resize operation, as in up, down and round, the texture coordinates are 0 to 1 across the longest dimension and adjusted by the image aspect ratio across the shorter dimension so that image pixels will remain square if texture mapped onto a square patch." I believe this excerpt supports the power of two link that I quoted in post #22.

thanks for finding that...   So if poser does go by this then it makes sense to use images sized to the power of two.  But then why let you change max texture size in render settings?.... lol
thats poser for ya..

Quote - What would really be cool (though I don't expect to see this happen anytime soon) is if Poser used some sort of mip-mapping; converting texture sizes based on camera distance. A (power of 2) pixel texture size from one ^ 2 to (say, arbitrarily chosen value of) 2048 ^ 2 are all stored on the same map, whose proper resolution is loaded into memory on demand, which reduces (texture) memory footprint from (arbitrarily chosen value of) 250MB to 10MB. IMHO this is why Poser is occassionally instable, especially throwing 25 copies of 4K ^ 2 textures at it. Does one really need this resolution if they are NOT rendering for the silver screen?

Mip-maps are being used since version 7 including and on-demand texture cache.

replicand:

Googling for the excerpt you quoted, I found that on documentation for the "txmake" utility, which was a utility for converting an arbitrary image into a renderman texture file.

That information was published in 1998. I'm just speculating here, but I think the Poser shader has moved on a bit from those days. Consider that at the time the renderman spec also said that no raytracing is done. Clearly we have raytracing now, so it is reasonable to presume that we also have arbitrary size texture mapping now.

I'm kind of curious now - exactly where are we here with Poser 6 and Poser 7. Clearly, P7 does mipmapping and also is a lot smarter about how, when, and how much of the image data is loaded into memory. P6 would run out of memory because of textures much sooner than P7 does.

On the subject of powers of 2 in general, they do come up a lot in performance considerations because of how numbers are represented and how arithmetic is done in binary, particularly from a historical viewpoint.

There are, of course, many operations that need to be performed on numbers in a program, but the fundamental ones available to programmers are:

Add (+)
Subtract (-)
Multiply (*)
Divide (/)

Of those, add and subtract have always been cheap, multiply used to be expensive, and divide used to be even more expensive. By expensive, I mean how long did it take for the computer to do it. Typically, we measure execution time in terms of the number of clock cycles required. Clock cycles are what drives all modern digital hardware. Everything happens at a minimum over a period of one clock cycle. If (as it was back in 1982, on an 8086 processor) your clock is running at about 8 megahertz, and adding takes 3 cycles, the most number of adds per second possible was about 2.6 million. Back then a 16-bit multiply took, on average, 115 clock cycles, and a 16-bit divide was a whopping 144 to 162 clock cycles. You could only expect to get around 56000 divides done per second, best case and if you had to go out to memory to get your numbers it was even slower.

But there are a couple other operations that are not strictly arithmetic, but have to do with stuff that is just easy to do. One of these is shifting - move all the bits in a number some number of places to the left or the right. Because of how binary representation works, shifting is arithmetically identical to multiplying (shift left) or dividing (shift right) by a power of 2. For example, x << 3 is the same as x * (2 to the power 3) or x times 8. Similarly, x >> 10 is exactly the same as x divided by 1024.

Now consider looking up a texture coordinate in a color map. This would involve a multiply or a divide or both depending on what you used to represent a texture coordinate. But!!! If the texture size is a power of 2, you can get away with just using a shift instead of a general multiply or divide. A "shift arithmetic right" on an 8086 processor only takes 2 cycles!!!! So you could do 4 MILLION of these per second, instead of 56000 per second. That's a whopping big improvement and would highly motivate you to arrange things so that shifting is a possibility instead of multiplication and division.

By the time the 80486 came around, a multiply was 13 to 26 clock cycles - a huge improvement. And, on top of that, clock speeds were now around 50 megahertz, 5 times as many per second!!! But shift had improved as well. It was now just ONE clock cycle. So - 50 million shifts per second vs. 3.8 million multiplies per second - which would you choose?

With all the newer Pentium processors containing multiple parallel arithmetic logic units, SIMD instructions sets, pipelined architectures, and micro clocking, its a bit harder to judge exactly how long things take, but suffice it to say that shifting instead of dividing is not the big win it used to be.

Sorry to be so long-winded, but I thought some people might find this interesting.

The bottom line is that the renderer and shaders are doing a lot more work than just looking up textures in a mipmap. So, the "power of 2" optimization is not as big as it used to be, and in any case it forms a much smaller part of the work being done to render your scene. 

It would be nice if stewer would come back and tell us if the power-of-2 lookup is still being used or not. I'm betting it isn't.

bagginsbill:

informative indeed. Have not upgraded to P7 and thus unaware of its mip-mapping capabilities. Yes, the information in that thread was taken from txmake utility, which it still distributed with Renderman for texture conversion. mental ray has a similar converter.

I'm at work so I can't consider this as well as I'd like. Shift registers and adders were always shaky area for me.

Quote - It would be nice if stewer would come back and tell us if the power-of-2 lookup is still being used or not. I'm betting it isn't.

(caution, tech talk ahead) Well, the whole concept of mip maps is that one mip level is half the width and half the height of the level below it. Thus, it's a repeated divison by two meaning that unless your texture sizes are powers of two, there will be at some point an odd size divided by two. Resampling for the higher levels is done using a filter kernel which in the case of an uneven divide would then not be centered on each pixel any more but sit between pixels at some point. If one used a simple narrow box filter or nearest-neighbor resampling, this would lead to visible aliasing. The use of wider higher-order filters however makes this not an issue in practice. Lookups in the mip map are not just a simple nearest-pixel read but depending on the filter setting a trilinear ("Fast") or an EWA ("Quality") lookup which makes this even less of an issue. BTW, when filtering is disabled in the material room, it's a bilinear interpolation from the lowest mip map level (thus leading to higher stress on the texture cache, possibly resulting in slower performance compared to trilinear or EWA lookups). Graphics cards usually prefer power of two sized textures and for preview purposes, Poser will resize textures appropriately. On the topic of txmake, that's a part of Pixar's implementation and not a part of the RenderMan specification. How a compliant renderer wants to deal with textures (mip map, rip map, summed area tables etc) is up to the implementation.

"I dont agree. I can write a program that will keep any size texture in memory that I want it too. The computer itself doesnt care what size the texture is. Poser itself might do this but it has nothing to do with the way computers work." (and some subsequent posts...)

Agreed. I was being a bit too generalistic, in the interests of simplicity.

I'm not 100% sure of this (it was a long time ago) but IIRC there's a "Block Copy" instruction for the Intel instruction set that takes as one of its modifiers a number that is, effectively, the "power of 2" number of bytes to copy. Since it is a single machine instruction it operates considerably faster than a loop of several single-byte (or word) machine-code copy operations.

That was then. Things may have improved since. But much of the "legacy" code that still abounds in Poser (and many other apps that need to move large lumps of data around - including Windows) make use of the "low-level" functions that utilise this facility.

That was what I meant by "the way computers work". Moving in "powers of two" is (often a lot) faster than moving arbitrary amounts on arbitrary byte boundaries. Its the usual trade-off between speed versus memory.

That's all..

Cheers,
Diolma

It sure would be nice to have a look at the poser sdk, but I dont see that happening any time soon. 
diolma: yeah I would hope that they optimised their code with inline assembly but who knows.

Quote -
to the computer 1024 is just a number.. the same as 3 or 7.

Not quite.  Using a decimal (or similar system), there's no difference between 3 and 7 (other than their value).  Each represents a single character.  That's not true in binary, where 3 needs two bits to define it (11) and 7 needs 3 (111).

Quote - > Quote -

to the computer 1024 is just a number.. the same as 3 or 7.

Not quite.  Using a decimal (or similar system), there's no difference between 3 and 7 (other than their value).  Each represents a single character.  That's not true in binary, where 3 needs two bits to define it (11) and 7 needs 3 (111).

yeah and 8 needs 4 bits...
gonna write us a program in binary? 

this threads gone astray in a hurry..

Interesting stuff indeed,

I have noticed that alot of texures for products here and at other places, have textures that are 3000x3000, does that mean that Poser 7 or Carrara(as I use this also), is having to allocate memory to this texture as if it was actually 4096x4096.

The reason I ask is that I regularly reduce my texures by half to get better memory usage so (3000x300 would become 1500x1500. But is the reality that the software or my system, will actually 'optomise' this texture size to 2048x2048, which would mean I am not getting the memory saving's that I expected.

Or am I just way off  base.???

I can't speak for Carrara, but in the case of Poser 7 you don't have to worry, it won't allocate excess memory just to get to a power of two. In the case of FireFly rendering, you don't have to worry about texture size at all - if you use 1,200x1,200 or 12,000x12,0000 textures will make barely any difference in terms of memory footprint.

OK well Stewer seems to be telling us, without actually having come right out and said it, that Poser internally increases the base texture size to a power of two, in preparation for doing mipmapping. This would imply that a 3K texture is actually taking up space as if it was 4K.

First point - should you then bother making a 3K texture at all, or just go to 4K? I'm guessing 4K.

Second point - I am certain that, other considerations (such as mipmapping) aside, it is possible to retain a 3K x 3K image in memory of exactly 27 megabytes (9 million pixels times 3 bytes per pixel). Almost all programs dealing with images do this. It's not tricky. If you were writing a program to manipulate and draw a 3K x 3K image and had no compelling mathematical reason to extend it to 4K, then you would not use much more memory than the minimum. For other efficiency reasons having to do with memory management, you might round it up to a multiple of some relatively small fixed chunk size, such as 1024, in which case you'd be wasting at most 1023 bytes. But there is no "software engineering" generic reason you have to go to 16 million pixels in memory.

Third point - power-of-two mipmapping was the state of the art several years ago. But I was able to find at least one very explicit paper on how to do non-power-of-two mipmapping. Yes it is slightly more complex. The algorithm was published by NVidia, explaining how to do it in hardware accelerated video cards. Typically, software techniques, which have a much bigger time budget (hours to render one image) can afford to do even more complex things than are done in real-time rendering. If real-time non-power-of-two rendering is possible, then there's no excuse why it should not be in Poser.

Here is the link to the article:

developer.nvidia.com/object/np2_mipmapping.html

Whoops cross post. Damn it. Cancel what I said at first.

Still though have a look at the non-power-of-2 mipmapping white paper.

Quote - OK well Stewer seems to be telling us, without actually having come right out and said it, that Poser internally increases the base texture size to a power of two, in preparation for doing mipmapping.

No, you are misinterpreting me here. It is not doing that.

Quote - No, you are misinterpreting me here. It is not doing that.

Yeah I saw your clarification after I posted. Sorry about the cross post. But what do you think about the nvidia non-power-of-2 mipmap algorithm?

Nvidia's algorithm is clearly aimed at real-time by being on the speed side of the speed/quality trade-off. While it is a clear improvement over a simple box filter, it is still a comparably low-quality filter they're using. Unfortunately, the paper shows only a coarse checkerboard texture, it would be interesting to see how good it is at eliminating aliasing whith textures that have fine 1-pixel lines. Poser's mip map generation is loosely based on OpenEXR's exrmaktetiled. You can get the source code of exrmaktetiled at http://www.openexr.com/.

Here's a render with 1024x1024 textures.. It was done in P6 and maybe we can get some info on how P6 handles textures is different than P7.