I recently made a texture which uses a single image file as an image_map and
a bump_map, roughly like this:

texture {
  pigment {
    image_map { png "a_large_image.png" }
  }

  normal {
    bump_map { png "a_large_image.png" }
  }
}


This material appears to use twice as much memory as the same texture with
either map removed (going by the after-render statistics for "Peak memory
usage" reported by POV). This also happens if you just declare two separate
pigments that use the same file as an image_map. Given the images I'm using
are >100MB uncompressed, this ends up being quite crippling.

Is there a way around this, preferably using the SDL? I'm looking into
image_pattern: can that help by eliminating unnecessary mentions of this
external image? I'd also like to know if this is "fixable" at the source
level, or if it's inherent to POVRay's design at the present time (or is
desirable or necessary for some reason), before I think of getting the
compiler out.

I've seen this on POVRay for Windows 3.5 and 3.6.1, and on MegaPOV 1.2
(windows version).

Post a reply to this message

Tom York <alp### [at] zubenelgenubi34spcom> wrote:
> Is there a way around this, preferably using the SDL?

  Actually I'm not sure if it's possible at all.

  You could try, however, to see what happens if you #declare your pigment
as an identifier and then use it in a pigment function. I haven't actually
tried if POV-Ray copies the image data for the pigment function or not.
  It it doesn't then you can use the declared pigment as the pigment of
your object and the function as a pattern in your normal block (with
something like normal { function { TheImage(x,y,z).gray } ... }).

-- 
                                                          - Warp

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
>   Actually I'm not sure if it's possible at all.
>
>   You could try, however, to see what happens if you #declare your pigment
> as an identifier and then use it in a pigment function. I haven't actually
> tried if POV-Ray copies the image data for the pigment function or not.
>   It it doesn't then you can use the declared pigment as the pigment of
> your object and the function as a pattern in your normal block (with
> something like normal { function { TheImage(x,y,z).gray } ... }).

Thanks, Warp! That method does fix the memory use issue! I'm left with a
question about using pigment functions in normals; it seems to me that they
produce an image which is similar, but not identical to the case where a
pigment is used directly in a normal. For instance, if you use something
like

normal {
  cells
  scale 0.4
}

in a texture, the resulting normal seems "more concentrated"* than if you
use
cells in a function and then use the function in the normal block, say:

#declare Nfunc = function { pigment { cells scale 0.4 } }

normal { function { Nfunc(x,y,z).gray } }

Using bump_size to reduce the normal strength just makes the pattern
fainter, not closer to the ordinary pattern-in-normal version. It seems to
happen with pigments based on external images, or on the cells,
cylindrical, or onion patterns (I haven't tested others).

*I will post an example in p.b.i.

Post a reply to this message

Tom York <alp### [at] zubenelgenubi34spcom> wrote:
> in a texture, the resulting normal seems "more concentrated"* than if you
> use
> cells in a function and then use the function in the normal block,

  I wonder if it's just a question of 'accuracy'. (IOW povray uses a
different default 'accuracy' value for the two cases you mention.)

  Try using different values of 'accuracy' (values closer to 0 will give
sharper normals).

-- 
                                                          - Warp

Post a reply to this message