I have developed a new feature for Megapov which I call a "Tile map".
This is an image map, where each pixel of the image is another image. Go
look on povray.binaries.images for an example.

The really significant part, which makes this patch different from just
tiling the images separately in some other program and using the
composite in pov, is that the tiles can be sparse. The example image is
specified to be an array of 6x6 tiles, but only 13 of those tiles are
specified. The rest are transparent, and take only a tiny amount of
memory overhead, compared to an occupied tile.

I wrote this to take advantage of the Blue Marble dataset from NASA. It
is an image 86400x43200 pixels big, which when unpacked into memory
would take 11GiB. This is no good. What I have done is broken the image
up into tiles, and wrote some script which decides which tiles are
visible and close enough to need the full resolution, and only loads
those tiles.

I would like to see this patch incorporated into the next version of
Megapov. Who do I have to bribe in order to get that to happen? Aside
from this one, I have about 6 other patches I would like to get into
Megapov.

I will post the patch some time in the future, especially if anyone
shows any interest.

Post a reply to this message

Chris Jeppesen wrote:
> 
> I would like to see this patch incorporated into the next version of
> Megapov. Who do I have to bribe in order to get that to happen? Aside
> from this one, I have about 6 other patches I would like to get into
> Megapov.

This is strongly influenced by the following points:

- is there interest in using the patch?
- does the syntax/usage make sense, is the solution well suited for the 
problem it is intended for?
- is the patch well written?
- is the patch sufficiently documented?
- has the patch already been tested?

Concerning your specific addition i have a few questions:

1) why is it restricted to image maps?
2) does it handle interpolation across the tile boundaries? (only makes 
sense with (1) of course, difficult with different resolution tiles)
3) why is it restricted to a regular rectangular pattern?

What would be really interesting is a dynamically cached image map (i.e. 
one that actually loads tiles on demand).  You would have to be careful 
when using the internal image reading functions for this though - they 
are not really intended to be used at render time.

Christoph

-- 
POV-Ray tutorials, include files, Landscape of the week:
http://www.imagico.de/ (Last updated 20 Aug. 2006)
MegaPOV with mechanics simulation: http://megapov.inetart.net/

Post a reply to this message

Christoph Hormann <chr### [at] gmxde> wrote:
> What would be really interesting is a dynamically cached image map (i.e. 
> one that actually loads tiles on demand).  You would have to be careful 
> when using the internal image reading functions for this though - they 
> are not really intended to be used at render time.

  One possibility would be to temporarily write the image in raw format
onto a file and then read parts of that file on demand. This would just
consume disk space instead of consuming RAM.

  The difficulty in this is how to decide when to drop image parts from
the cache. There's no universal way of knowing how much memory is
available. One possibility would be for the user to specify manually
some value.

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
> 
>   One possibility would be to temporarily write the image in raw format
> onto a file and then read parts of that file on demand. This would just
> consume disk space instead of consuming RAM.

That would mean unnecessarily copying possibly lots of GB and in case of 
a compressed format also decompressing it - data that is possibly not 
needed at all since the render only uses a small part.

If such a patch is developed it would be good to have both the 
possibility to use large uncompressed files directly and alternatively 
to specify already existing tile images that can directly be used for 
the dynamic caching.  Often when dealing with large images you have them 
in form of tiles anyway to simplify handling and local modifications.

What would make sense for compressed formats is to temporarily store 
expired tiles to disk to avoid decompressing them again in case they are 
needed.

>   The difficulty in this is how to decide when to drop image parts from
> the cache. There's no universal way of knowing how much memory is
> available. One possibility would be for the user to specify manually
> some value.

That's what makes most sense i suppose (having the possibility to 
specify the tile size and the number of tiles to keep would allow 
detailed control over the performance).

Christoph

-- 
POV-Ray tutorials, include files, Landscape of the week:
http://www.imagico.de/ (Last updated 20 Aug. 2006)
MegaPOV with mechanics simulation: http://megapov.inetart.net/

Post a reply to this message

Christoph Hormann wrote:
> Chris Jeppesen wrote:

> Concerning your specific addition i have a few questions:
> 
> 1) why is it restricted to image maps?

I'm not sure that it is, it is just that I have never tried it for
anything else. My particular application only needs image maps. It is
implemented as a new image type, so it might "just work" anywhere an
image is needed.

> 2) does it handle interpolation across the tile boundaries? (only makes
> sense with (1) of course, difficult with different resolution tiles)

Probably not. Again, I haven't tested it in this condition. At the
moment, I'm not even sure that it handles interpolation properly within
a tile.

This patch will work (without interpolation) for tiles of different
resolutions, but I am not sure what would happen with tiles of different
color types (grayscale, indexed, rgb). I suspect it would still work in
this case, but I haven't tried it.

> 3) why is it restricted to a regular rectangular pattern?

Are you suggesting triangles and hexagons? Or a rectangular map with a
different number of tiles in each row? I thought about the latter, and
that can be implemented using nested tilemaps. Since with this patch a
tilemap is just another image type, it can be used anywhere any image
type can be used, including as the definition for another tilemap. For
instance, the outer tilemap is 1 column by n rows, and each row is an
inner tilemap with q columns by one row, where q is different for each row.

I guess the answer to all three questions is "That's not how I use it",
and that's not a good answer in order to get this patch included.
However, it has been my experience that there are lots of creative
people out there who can squeeze stuff out of a feature that the
programmer never even considered. If this patch were included, some
artist somewhere would surprise me.

> 
> What would be really interesting is a dynamically cached image map (i.e.
> one that actually loads tiles on demand).  You would have to be careful
> when using the internal image reading functions for this though - they
> are not really intended to be used at render time.

Interesting. For my application, I have a script which determines which
tiles will be visible in a scene, and close enough to the camera to
matter, and pre-loads those. Since I know in advance that all tiles will
be used, it doesn't seem to make sense to have a dynamic loading system
like this.

> 
> Christoph
> 

In order to be reviewed, should I post the patch here? Where should I
put patches?

Chris

Post a reply to this message

Chris Jeppesen wrote:
> 
> In order to be reviewed, should I post the patch here? Where should I
> put patches?

You can post small patches to povray.binaries.programming but if you 
want to include documentation, sample scenes etc. it is probably better 
to put up a web page somewhere.

Christoph

-- 
POV-Ray tutorials, include files, Landscape of the week:
http://www.imagico.de/ (Last updated 20 Aug. 2006)
MegaPOV with mechanics simulation: http://megapov.inetart.net/

Post a reply to this message