I recently discovered image map alpha channel transparency and have a couple
of questions/observations:

(1) I did some comparison tests between differencing out ten holes in the
side of my model airplane to create windows vs. using a PNG image map where
the alpha channel holes in the map create the transparencies. I was
expecting the image map method to be slightly faster, but it was
consistently over 40% faster (and the gap only widened as I added more
windows). Can anyone who is familiar with the internal workings of POV-Ray
explain why this is so? Intuitively it would seem that using image map
transparency "stores" the differencing calculations statically so they're
only calculated once (when you create the image map in the first place, for
which I used POV-Ray, btw), and at runtime all of the differencing
calculations are unneeded; POV-Ray just wraps the image map around my
airplane fuselage cylinder and then creates a "hole" wherever a light ray
strikes a transparent pixel in the alpha channel of the image map... is that
a fair approximation of what's happening?

(2) Here's something I really don't understand: Obviously the trade-off of
using image maps vs. differencing is that you must use fairly large image
files to get acceptable results; otherwise, if the camera gets too close to
the model you start to see jagged edges around the window "holes". But when
I created a 4000x4000 version of my image map, the rendering time was almost
*exactly* the same as when I was using a 1000x1000 PNG file. The amount of
memory used jumped considerably, of course, but the average rendering time
between the 1000x1000 and 4000x4000 image maps was essentially unchanged. Is
that about right?

TIA...
Scott Gammans

Post a reply to this message

message de news:3f8ad0f5$1@news.povray.org...
> calculations are unneeded; POV-Ray just wraps the image map around my
> airplane fuselage cylinder and then creates a "hole" wherever a light ray
> strikes a transparent pixel in the alpha channel of the image map... is
that
> a fair approximation of what's happening?

Other people will explain the details, but differencing many objects from a
main one is not very efficient and leads to long render times. The trick is
to cut the object in several pieces, have 1 or 2 difference per piece and
then union{} the pieces. Of course, this is not always possible but any
repeating objects such as windows should be treated that way whenever
possible.

> (2) Here's something I really don't understand: Obviously the trade-off of
> *exactly* the same as when I was using a 1000x1000 PNG file. The amount of
> memory used jumped considerably, of course, but the average rendering time
> between the 1000x1000 and 4000x4000 image maps was essentially unchanged.
Is
> that about right?

Experience shows that image_maps are very efficient so it's not really
surprising. The worse that can happen is RAM trouble.
About the jaggies, did you try interpolate 2 on the maps ? It can help
sometimes.

G.

-- 

**********************
http://www.oyonale.com
**********************
- Graphic experiments
- POV-Ray and Poser computer images
- Posters

Post a reply to this message

Hi Gilles! Thanks for the fast response.

> Other people will explain the details, but differencing many objects from
a
> main one is not very efficient and leads to long render times. The trick
is
> to cut the object in several pieces, have 1 or 2 difference per piece and
> then union{} the pieces. Of course, this is not always possible but any
> repeating objects such as windows should be treated that way whenever
> possible.

And this is one of those cases where it wouldn't be practical. My model has
some pretty complex shapes other than cylinders which have transparencies,
and differencing those shapes into pieces ground my workstation to a halt
(some of the shapes are sheared with matrix{} and differencing something
that has been matrix-sheared didn't seem to work too well).

> Experience shows that image_maps are very efficient so it's not really
> surprising. The worse that can happen is RAM trouble.

I guess that makes sense... why calculate a hole when you can look it up in
a static bitmap? As for memory, my workstation has 2 GB of RAM so I don't
think memory will be a problem.

> About the jaggies, did you try interpolate 2 on the maps ? It can help
> sometimes.

I knew I forgot to ask something in my original message... yes, I did try
interpolation and method 2 (bilinear interpolation) seems to give the best
results as the POV-Ray help file suggests. I still get better results going
with a higher-rez bitmap, but only for extreme closeups, so I'm content to
create two sets of image and bump maps (one set of low-rez maps for
animations and distance shots, and one high-rez set). But here's the
thing... when interpolation 2 is selected for all of my image/bump maps, the
rendering time slows down only slightly (very nearly within the range of
statistical insignificance, from the 10 test runs I performed) over using no
interpolation at all. So my question is, why would you *not* want to use
bilinear interpolation on your image and bump maps?

Thanks!

Post a reply to this message

Wasn't it Scott Gammans who wrote:
>I recently discovered image map alpha channel transparency and have a couple
>of questions/observations:
>
>(1) I did some comparison tests between differencing out ten holes in the
>side of my model airplane to create windows vs. using a PNG image map where
>the alpha channel holes in the map create the transparencies. I was
>expecting the image map method to be slightly faster, but it was
>consistently over 40% faster (and the gap only widened as I added more
>windows). Can anyone who is familiar with the internal workings of POV-Ray
>explain why this is so? Intuitively it would seem that using image map
>transparency "stores" the differencing calculations statically so they're
>only calculated once (when you create the image map in the first place, for
>which I used POV-Ray, btw), and at runtime all of the differencing
>calculations are unneeded; POV-Ray just wraps the image map around my
>airplane fuselage cylinder and then creates a "hole" wherever a light ray
>strikes a transparent pixel in the alpha channel of the image map... is that
>a fair approximation of what's happening?

You may find some enlightenment as to what's happening in my Holes
Tutorial <http://www.econym.demon.co.uk/holetut/>. Or by taking a close
look at the differences in the statistics that are produced when you run
the scenes.

Basically what happens is that POV can't create efficient automatic
bounding for differences, so each ray is being tested against the
fuselage and against every object that's differenced from it. So if you
have 10 windows, each ray is being tested for intersection with 11
objects. The more windows you have, the more intersection tests are
performed on each ray.

If you use the alpha channel approach, then each ray is only being
tested against the single fuselage object. The number of holes doesn't
affect the number of intersection tests.

>(2) Here's something I really don't understand: Obviously the trade-off of
>using image maps vs. differencing is that you must use fairly large image
>files to get acceptable results; otherwise, if the camera gets too close to
>the model you start to see jagged edges around the window "holes". But when
>I created a 4000x4000 version of my image map, the rendering time was almost
>*exactly* the same as when I was using a 1000x1000 PNG file. The amount of
>memory used jumped considerably, of course, but the average rendering time
>between the 1000x1000 and 4000x4000 image maps was essentially unchanged. Is
>that about right?

It takes exactly the same amount of processing power for POV to look up
the contents of point <2000,2000> in a 4000x4000 image map as it does to
look up the contents of point <500,500> in a 1000x1000 image map. As
long as you have enough free physical memory to hold the whole of the
large image in RAM the speed should be the same.

If you can derive an equation which specifies where the windows are
located, then you could use a pigment function instead of an image map.
This should give you smooth edges at any magnification. This should be
nearly as fast as using an image map unless your equation turns out to
be very complicated.

The one thing that you can't do with the alpha channel approach is to
deal with a fuselage that has thick walls. 

-- 
Mike Williams
Gentleman of Leisure

Post a reply to this message

Hi Mike,

> You may find some enlightenment as to what's happening in my Holes
> Tutorial <http://www.econym.demon.co.uk/holetut/>. Or by taking a close
> look at the differences in the statistics that are produced when you run
> the scenes.
>
> Basically what happens is that POV can't create efficient automatic
> bounding for differences, so each ray is being tested against the
> fuselage and against every object that's differenced from it. So if you
> have 10 windows, each ray is being tested for intersection with 11
> objects. The more windows you have, the more intersection tests are
> performed on each ray.

That makes eminent sense... thanks for the 'splanation (and the online
tutorial!)

> If you can derive an equation which specifies where the windows are
> located, then you could use a pigment function instead of an image map.
> This should give you smooth edges at any magnification. This should be
> nearly as fast as using an image map unless your equation turns out to
> be very complicated.

I learn something new about POV-Ray every day, it seems like. I never
understood what Function Image was for until you gave that example just now.
Fascinating... I will definitely give that a try.

> The one thing that you can't do with the alpha channel approach is to
> deal with a fuselage that has thick walls.

You can't? That's not what I'm seeing. My fuselage has walls which are 0.1
POV-Ray units thick. Image-mapped alpha transparency seems to work just
fine... there's definitely a recessed, three-dimensional appearance to the
windows, just like I had when I was differencing the holes out. By "thick
walls" do you mean, for example, 1 POV-Ray unit thick on an box{5,-5} (i.e.,
a wall with a thickness that is a significant % of the size of the object)?

Thanks for taking the time to respond.

Post a reply to this message

message de news:3f8aecab$1@news.povray.org...

> And this is one of those cases where it wouldn't be practical. My model
has
> some pretty complex shapes other than cylinders which have transparencies,
> and differencing those shapes into pieces ground my workstation to a halt
> (some of the shapes are sheared with matrix{} and differencing something
> that has been matrix-sheared didn't seem to work too well).

To be frank, when one wants to model real-life objects with a certain
accuracy, primitives and CSG do have limits and the price to pay in terms of
conception and rendering time may just be too high. Curves, bevels, holes
and uv-mapping are more the realm of mesh modellers.

> interpolation at all. So my question is, why would you *not* want to use
> bilinear interpolation on your image and bump maps?

I agree that interpolation could certainly be turned on by default. This is
probably a legacy issue, as this may not have been desirable when 386s were
considered as fast machines. There are other features in the same situation
actually (ambient > 0 in standard textures for instance).

G.

-- 
**********************
http://www.oyonale.com
**********************
- Graphic experiments
- POV-Ray and Poser computer images
- Posters

Post a reply to this message

In article <3f8ad0f5$1@news.povray.org>,
 "Scott Gammans" <dee### [at] yahoocom> wrote:

>  Intuitively it would seem that using image map
> transparency "stores" the differencing calculations statically so they're
> only calculated once (when you create the image map in the first place, for
> which I used POV-Ray, btw), and at runtime all of the differencing
> calculations are unneeded; POV-Ray just wraps the image map around my
> airplane fuselage cylinder and then creates a "hole" wherever a light ray
> strikes a transparent pixel in the alpha channel of the image map... is that
> a fair approximation of what's happening?

It doesn't create a hole, the surface is still there, it is just 
transparent. This technique is a sometimes-useful hack, but does not 
have any actual effect on the geometry of the object.


> (2) Here's something I really don't understand: Obviously the trade-off of
> using image maps vs. differencing is that you must use fairly large image
> files to get acceptable results; otherwise, if the camera gets too close to
> the model you start to see jagged edges around the window "holes". But when
> I created a 4000x4000 version of my image map, the rendering time was almost
> *exactly* the same as when I was using a 1000x1000 PNG file. The amount of
> memory used jumped considerably, of course, but the average rendering time
> between the 1000x1000 and 4000x4000 image maps was essentially unchanged. Is
> that about right?

The work to find the pixels involved and interpolate between them is 
constant, and independent of the resolution of the image. Pretty much 
just clamp the coordinates to [0, 1], multiply by the width and height 
and round down to get one corner pixel, and simply add integers from 
there. It will be slightly slower due to more memory being accessed, but 
probably not by enough to reliably measure. Unless you run out of RAM 
and start swapping...

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/

Post a reply to this message

In article <3f8af8e2$1@news.povray.org>,
 "Scott Gammans" <dee### [at] yahoocom> wrote:

> You can't? That's not what I'm seeing. My fuselage has walls which are 0.1
> POV-Ray units thick. Image-mapped alpha transparency seems to work just
> fine... there's definitely a recessed, three-dimensional appearance to the
> windows, just like I had when I was differencing the holes out. By "thick
> walls" do you mean, for example, 1 POV-Ray unit thick on an box{5,-5} (i.e.,
> a wall with a thickness that is a significant % of the size of the object)?

If you take a closer look, you will see that the holes have no "sides". 
You are just making transparent areas in the skin of the object, the 
result will look like two thin layers. Irregular holes will look 
especially bad this way. And it does depend on thickness, but there 
isn't any simple relation, it depends highly on the situation. You will 
probably usually get away with it in paper-thin objects and other 
situations where you wouldn't see the sides of the hole.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/

Post a reply to this message

In article <3f8aecab$1@news.povray.org>,
 "Scott Gammans" <dee### [at] yahoocom> wrote:

>  So my question is, why would you *not* want to use
> bilinear interpolation on your image and bump maps?

Pretty much only if you want the mosaiac effect of nearest-neighbor. The 
speed issue was more important on older computers, when just displaying 
the image was a significant amount of work for a machine to do.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/

Post a reply to this message

> If you take a closer look, you will see that the holes have no "sides".
> You are just making transparent areas in the skin of the object, the
> result will look like two thin layers. Irregular holes will look

Hmm, yes, if I get really, really close I do see two thin layers. I would
have to get so close, though, that the ragged edges of the image maps would
be more noticeable. From the distances that I'm planning to view the model,
the eye is fooled into seeing the two ultra-close layers as one "wall".

Post a reply to this message