ingo wrote:
>using the option to use bitmaps as a function
>for an isosurface object in the
>superpatch might be what you're looking for

Using the isosurface patch is probably
unnecessary for what I'm trying to do.
It would basically shift the process
from bumpmapping to displacement mapping,
and although the results would look good,
the additional rendering time would negate
the benefits severely. But in the future,
it's an area definitely worth exploring.
Actually, what I'm proposing should be
seamlessly usable by the isosurface patch
anyway.

My proposed changes basically enhance the
use of imagemaps/bumpmaps so that really
large (e.g., 128 MB) maps can be used
without taking memory.

Why large maps? For terrain, I use
fractal plasma bumpmaps, and initially
I was calculating them dynamically
during the rendering process. But this
is really slow, and it's difficult to
get the overall map to look right.
When I realized I was using the same
bumpmap data repeatedly, it made sense
to generate a large map once, thereby
caching all that computation.

The map has to be large so that close-up
views look good. If you've ever walked up
close to a wall in Quake, you know
what I mean -- the texture breaks down
into obvious pixels. Given today's
big and cheap hard drives, storage of
large maps is no longer a problem.

POV-Ray doesn't support large maps well;
it assumes they can be loaded entirely
into memory and kept around for the duration.
This is okay for simple scenes, but for
complex scenes, it doesn't make sense to
share memory with a large imagemap/bumpmap.
Virtual memory doesn't help either, since
it's not optimized for the type of caching
the maps need (and on a complex scene,
the VM is needed for other objects anyway).

So that's basically it. One nice thing is
that the visible impact on POV-Ray would
be minimal -- there's no language changes
or anything new to learn. All that happens
is that if you're using a large bumpmap/imagemap,
it gets used in an optimum way that leaves
memory for the rest of the scene. Adding
support for a true 16-bit bumpmap/grayscale filetype
would be nice, and that would be the only
language modification.

Ray
Daylon Graphics Ltd.
http://www.daylongraphics.com/

Post a reply to this message

POV already supports at least one true 16-bit image format: PNG.
I think TIFF support would be a nice addition, though.  Maybe
I'll see what's involved.

The problem with any sort of code that would access the image
when the information was needed is that many image formats,
including PNG and GIF, are not particularly conducive to being
read out of order.  That's probably part of why BMRT and PRMAN 
use TIFF images as maps.  We could perhaps get away with using 
TGA or BMP images, both of which have common uncompressed formats 
that could be used effectively enough to access images by blocks
(though BMP isn't supported on non-Windows ports of POV.)  The 
actual modifications probably wouldn't be too drastic.

And yes, this would directly affect the "displacement mapping" 
that's being done with isosurfaces, though perhaps not in a
good way.  The problem is that isosurfaces use a binary chop
sort of method to find the intersection.  Any normal caching
scheme would throw up its virtual hands in despair when 
confronted with the resulting access pattern.

Post a reply to this message

> POV already supports at least one true 16-bit image format: PNG.

Don't forget PGM (portable grey map) and the non-standard 16-bit TGA.
Perhaps you were pointing to 16-bit per channel color formats, but I
just thought I'd mention those.

> I think TIFF support would be a nice addition, though.  Maybe
> I'll see what's involved.

I would probably use that if it was available.

-Mike

Post a reply to this message

Mike wrote:
> > I think TIFF support would be a nice addition, though.  Maybe
> > I'll see what's involved.
> 
> I would probably use that if it was available.
> 
> -Mike

Which tiff format. There is something like 4 - 6 different versions and
some are completely different than there counterparts.

-- 
Ken Tyler
  
mailto://tylereng@pacbell.net
http://home.pacbell.net/tylereng/links.htm

Post a reply to this message

[Taken from Photoshop help file...]

The Tagged-Image File Format (TIFF) is used to exchange files between
applications and computer platforms. TIFF is a flexible bitmap image format
supported by virtually all paint, image-editing, and page-layout
applications. Also, virtually all desktop scanners can produce TIFF images.
The TIFF format supports CMYK, RGB, and grayscale files with alpha
channels, and Lab, indexed-color, and Bitmap files without alpha channels.
TIFF also supports LZW compression. You can choose to save in a format that
can be read either by IBM PC-compatible or Macintosh computers.Compressing
a TIFF file decreases its file size but increases the time required to open
and save the file. You can also read and save captions in TIFF files.

--
Anthony L. Bennett
http://welcome.to/TonyB

Non nova, sed nove.

Post a reply to this message

Ron Parker wrote in message <37a1f578@news.povray.org>...
>
>POV already supports at least one true 16-bit image format: PNG.
>I think TIFF support would be a nice addition, though.  Maybe
>I'll see what's involved.

From just a quick look at the code in png_pov.c, I couldn't
find any plain 16-bit support; there's always some conversion
of color channels going on. But I'm not 100% sure; will
have to look closer at it.


I just realized that no caching scheme may be effective,
because there will always be a scene that makes it thrash.

Consider a scene with multiple objects (all using the
same imagemap) at various distances from the camera.
As the rendering scanline intersects more than one object,
the access pattern to the imagemap becomes more random.

The solution is probably to build a depth map of the
entire scene, and then iterate through the imagemap
looking for screen pixels that can be serviced by
the current imagemap chunk. One nice thing is that
the storage format of the image file doesn't have
to be block-based; we can make a chunk be a set
of scanlines, so reading it is just as fast as
reading a block.

Ray Gardener
Daylon Graphics Ltd.
http://www.daylongraphics.com/

Post a reply to this message

On Fri, 30 Jul 1999 17:39:48 -0700, Ken wrote:
>
>
>Mike wrote:
>> > I think TIFF support would be a nice addition, though.  Maybe
>> > I'll see what's involved.
>> 
>> I would probably use that if it was available.
>> 
>> -Mike
>
>Which tiff format. There is something like 4 - 6 different versions and
>some are completely different than there counterparts.

TIFF 6.0, of course, unless there's something newer.  Not all parts, of
course.  For example, there could be no support for LZW compression on 
output.  As I said, I'll look into what's involved.  It may be more trouble
than it's worth, what with all the different chunks and color spaces and
such.  Still, ya gotta admit, it's the first choice of professional 
graphic artists.

Post a reply to this message

On Sat, 31 Jul 1999 10:32:36 -0700, Ray Gardener wrote:
>From just a quick look at the code in png_pov.c, I couldn't
>find any plain 16-bit support; there's always some conversion
>of color channels going on. But I'm not 100% sure; will
>have to look closer at it.


color = (int)floor(line_data[col][RED]   * 65535.0);

row_ptr[j] = color >> 8;
row_ptr[j + 1] = color & 0xFF;

(and three more just like it)

The color is pure sixteen-bit color at this point,
provided that the floating-point format of a COLOUR
structure is up to it. (the default is single-precision,
which ISTR has a 16-bit mantissa.  You could probably
get better color resolution with a double-precision 
custom compile.)  The two lines that bit-bang the 
result are just a portable way of explicitly handling
endianness issues in the resulting image file.

>Consider a scene with multiple objects (all using the
>same imagemap) at various distances from the camera.
>As the rendering scanline intersects more than one object,
>the access pattern to the imagemap becomes more random.

True, but there comes a time when you have to just accept 
that and move on.  Presumably the caching behavior would
be on an imagemap-by-imagemap basis, controlled by a keyword,
so small imagemaps would be no slower than ever.  And there's
no rule that says you have to keep only one current chunk.
If you kept the last n chunks for some (configurable?) value of 
n, you could still realize a performance improvement for the
vast majority of non-pathological scenes.

Actually, the worst scene I can think of is an infinite plane,
tiled with your bitmap of choice.  Samples near the horizon
will be almost completely random.

Post a reply to this message

Ron Parker wrote in message >
>
>color = (int)floor(line_data[col][RED]   * 65535.0);
>
>row_ptr[j] = color >> 8;
>row_ptr[j + 1] = color & 0xFF;
>
>(and three more just like it)


Phew; that's a relief.


>True, but there comes a time when you have to just accept
>that and move on.  Presumably the caching behavior would
>be on an imagemap-by-imagemap basis, controlled by a keyword,
>so small imagemaps would be no slower than ever.  And there's
>no rule that says you have to keep only one current chunk.
>If you kept the last n chunks for some (configurable?) value of
>n, you could still realize a performance improvement for the
>vast majority of non-pathological scenes.


Interesting coincidence -- a multi-chunk cache scheme
was the first thing I tried after the original post.
It floundered horribly; the number of chunks needed
to be kept present became too significant a percentage
of the entire imagemap, so all the memory savings evoporated.
No matter what, it was either have s-l-o-w rendering
or lots of memory being consumed.

I've now got a pure imagemap-driven system working,
and it's fast. The raytracer builds a depth map, the
imagemap enhances it with bumpmap data, and then a
final colorization pass whips over in two seconds.
Best of all, I can try different light positions/colormaps
afterwards and re-colorize instantly.


>Actually, the worst scene I can think of is an infinite plane,
>tiled with your bitmap of choice.  Samples near the horizon
>will be almost completely random.

Agreed. Even a single heightfield with some bumps closer
than others gave the cache scheme the fits. The whole
paradigm of servicing pixels off the raytracing scanline
is probably unsuitable for some things. I'm not suprised
things like REYES, etc. are used.

Ray Gardener
Daylon Graphics Ltd.
http://www.daylongraphics.com/
"heightfield editing perfected"

Post a reply to this message

Ron Parker wrote:
>  Still, ya gotta admit, it's the first choice of professional graphic artists.

I eructate in their general direction :)

-- 
Ken Tyler
  
mailto://tylereng@pacbell.net
http://home.pacbell.net/tylereng/links.htm

Post a reply to this message