POV-Ray : Newsgroups : povray.general : HELP: Saving Memory : Re: HELP: Saving Memory Server Time
3 Jul 2024 02:23:24 EDT (-0400)
  Re: HELP: Saving Memory  
From: clipka
Date: 16 Dec 2015 09:40:00
Message: <web.567177628c656afad6fa18f0@news.povray.org>
Sven Littkowski <jam### [at] yahoocom> wrote:
>
> I try to save memory, and wanted thus to prevent declaring one and the
> same (very large) image multiple times. This is, how I tried it:
....
> #declare MyHullPlating     = image_map { jpeg "Seneca II - Hull
> Plating.jpg"     interpolate 2 }
....
> #declare HullPlatingSquare     = pigment { image_map { MyHullPlating
>                                                               } }

The above should work fine...

> #declare HullPlatingSphere     = pigment { image_map { MyHullPlating
>                                 map_type 1                    } }

.... while this possibly won't. Likewise...

....
> #declare HullBumpNogatesWindowsSquare04 = normal { bump_map {
> MyInteriorPlating                                          bump_size 0.4 } }
> #declare HullBumpNogatesWindowsSquare10 = normal { bump_map {
> MyInteriorPlating                                          bump_size 1.0 } }

.... the above two statements should be fine...

> #declare HullBumpNogatesWindowsSphere04 = normal { bump_map {
> MyInteriorPlating                               map_type 1 bump_size 0.4 } }
> #declare HullBumpNogatesWindowsSphere10 = normal { bump_map {
> MyInteriorPlating                               map_type 1 bump_size 1.0 } }

.... while these again might not be.


> But POV-Ray seem not to like my intentions to save some memory.

IIRC, at present POV-Ray won't share images across different map flavors (e.g.
image_map vs. bump_map), nor with different interpolation, nor with different
projection (map_type) - or anything that is common to all statements that load
an image, for that matter.

bump_size should be fine; if it doesn't work, try moving it from the bump_map{}
block to the normal{} block.


I'm aware that there's room for improvement there; technically there's no reason
to glue stuff like the projection type and interpolation as tightly to the image
itself as it is currently done, and we should probably have some dedicated
statement to just load a "naked" image and assign it to a variable, to be used
later in image_map, bump_map or even height_field statements. And if I had a
bigger supply of round tuits, we'd already have something like that ;)


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.