This may well be a very old issue, but it bears repeating...

I can't get good quality sky_spheres using image_maps.  If I scale them
so that they repeat, I get a mirror effect if I look at certain angles
(camera { location < -945,287.0 ,  184> look_at <  400, 58.6 ,  0.0>
}).  I tried several translations to fix this; all proved futile.

If I use map_type 1, the effect is very blotchy.  I even made a 4x4 tile
of the original image in another program and combined that with
interpolate 2 in the image_map:

sky_sphere {
 pigment {
  #if (IsTest)
   rgb <0.1, 0.3, 0.8>
  #else
   image_map { png "sky6a.png" map_type 1 interpolate 2 }
   translate <0, -1, -1>
   scale .2
  #end
 }
}

The result was still unsatisfactory.  Try it with a 960x960 png (smaller
images show the problem even more) at 1280x1024.  Lowering the render
resolution actually improves the sky_sphere, but at an obvious cost.

The map_type 1 option in image_map ignores all other transformations.
The problems I have had with it have led me to openly question this
decision.  Simply allowing the frequency keyword here would save a lot
of trouble.  'interpolate 2' can only do so much, usually around the
edges of the pixel blocks.

There are some who would call this a feature limitation and therefore
beyond the scope of beta-test issues.  But if a limit on a feature makes
that feature unsuitable for its intended purpose, the 'limit' becomes a
'bug', IMHO.

Post a reply to this message

Attachments:
Download 'us-ascii' (2 KB)

Your HTML (or RTF) posting won't get as much attention, plain text is the
rule here.

I can only offer some feedback.  You were transforming a spherical map, you
did realize that?  It distorts the image terribly when a map meant to go
onto a sphere, such as the sky_sphere, is translated and scaled.  By doing
both you were effectively moving pixels around in odd ways.  Or maybe that
was your intent.

Looking again here at some image maps of both photos and graphics used in a
sky_sphere with either planar or spherical mapping I cannot see what you are
trying to describe.  Except that distortions do occur if used in
unconventional ways.

Using the new spherical lens camera is the only way to perfectly view a
sky_sphere I think.

Bob H.

"David Wallace" <dar### [at] earthlinknet> wrote in message
news:3BB9E6B5.83191D53@earthlink.net...
This may well be a very old issue, but it bears repeating...
I can't get good quality sky_spheres using image_maps.  If I scale them so
that they repeat, I get a mirror effect if I look at certain angles (camera
{ location < -945,287.0 ,  184> look_at <  400, 58.6 ,  0.0> }).  I tried
several translations to fix this; all proved futile.
If I use map_type 1, the effect is very blotchy.  I even made a 4x4 tile of
the original image in another program and combined that with interpolate 2
in the image_map:
sky_sphere {
 pigment {
  #if (IsTest)
   rgb <0.1, 0.3, 0.8>
  #else
   image_map { png "sky6a.png" map_type 1 interpolate 2 }
   translate <0, -1, -1>
   scale .2
  #end
 }
}
The result was still unsatisfactory.  Try it with a 960x960 png (smaller
images show the problem even more) at 1280x1024.  Lowering the render
resolution actually improves the sky_sphere, but at an obvious cost.
The map_type 1 option in image_map ignores all other transformations.  The
problems I have had with it have led me to openly question this decision.
Simply allowing the frequency keyword here would save a lot of trouble.
'interpolate 2' can only do so much, usually around the edges of the pixel
blocks.
There are some who would call this a feature limitation and therefore beyond
the scope of beta-test issues.  But if a limit on a feature makes that
feature unsuitable for its intended purpose, the 'limit' becomes a 'bug',
IMHO.

Post a reply to this message

"David Wallace" <dar### [at] earthlinknet> wrote in message
news:3BB9E6B5.83191D53@earthlink.net...
> This may well be a very old issue, but it bears repeating...
>
> I can't get good quality sky_spheres using image_maps.  If I scale them
> so that they repeat, I get a mirror effect if I look at certain angles
> (camera { location < -945,287.0 ,  184> look_at <  400, 58.6 ,  0.0>
> }).  I tried several translations to fix this; all proved futile.
>
> If I use map_type 1, the effect is very blotchy.  I even made a 4x4 tile
> of the original image in another program and combined that with
> interpolate 2 in the image_map:
>
> sky_sphere {
>  pigment {
>   #if (IsTest)
>    rgb <0.1, 0.3, 0.8>
>   #else
>    image_map { png "sky6a.png" map_type 1 interpolate 2 }
>    translate <0, -1, -1>
>    scale .2
>   #end
>  }
> }
>
> The result was still unsatisfactory.  Try it with a 960x960 png (smaller
> images show the problem even more) at 1280x1024.  Lowering the render
> resolution actually improves the sky_sphere, but at an obvious cost.
>
> The map_type 1 option in image_map ignores all other transformations.
> The problems I have had with it have led me to openly question this
> decision.  Simply allowing the frequency keyword here would save a lot
> of trouble.  'interpolate 2' can only do so much, usually around the
> edges of the pixel blocks.
>
> There are some who would call this a feature limitation and therefore
> beyond the scope of beta-test issues.  But if a limit on a feature makes
> that feature unsuitable for its intended purpose, the 'limit' becomes a
> 'bug', IMHO.
>

This is neither a bug nor a feature limitation. This is simple math. With a
960x960 image, and a default camera angle of 60 degrees, you are only ever
viewing
1/6 of the map or 160 pixels (horizontally) when they are stretched across
1280 pixels they will look blotchy. And yes, smaller image maps will look worse
because the stretching effect will be more pronounced. For exactly the same
reasons, smaller renders will produce less stretching.

There are however, a number of ways around the problem. For example, while image
maps don't support the frequency keyword, they can be mapped into a radial
pattern
that does. Another option: declare the image map as a planar map and pass the
appropriate parameters to a spherical_warp statement. This is the same as your
tiling solution without the overhead of an image tiled in a paint program.

You might also care to peruse the IRTC as I know there are at least two images
that recently used imaged mapped skies with fairly stunning results. Perhaps
comparing notes with their creators could lead to more satisfactory results for
you.


--
--
Batronyx ^"^
bat### [at] cadronhsacom //old & going away
bat### [at] alliancecablenet new & active now.
http://www.batronyx.com

Post a reply to this message

I can transfer an image_map to a radial pigment using pigment_map:

<code>
camera { location < -329,121.5 , 41.7> look_at < -600, 82.0 ,  0.0> }

#declare Sky1 = pigment { image_map { png "sky6.png" interpolate 2 } }
#declare Sky2 = pigment { image_map { png "sky6b.png" interpolate 2 } }

sky_sphere {
 pigment {
  #if (IsTest)
   rgb <0.1, 0.3, 0.8>
  #else
   radial
   ramp_wave
   frequency 6
   //turbulence 0.2
   //lambda 1.4
   pigment_map {
    [ 0.00 Sky1 ]
    [ 0.50 Sky2 ]
   }
   scale 0.5
  #end
 }
}
</code>

I get the same mirror problem at the yz-plane as a normal planar map, shown by the
given camera.  It's this mirroring of image_maps on sky_spheres that led me to use
map_type 1 in the first place.  I need a method that has no mirrors and still gives
a clean sky image_maps.  Turbulence is not the answer: the sky becomes surreal if I
use enough to hide the mirror effect.

Any ideas?

Batronyx wrote:

> For example, while image maps don't support the frequency keyword, they can be
> mapped into a radial pattern that does. Another option: declare the image map as a
> planar map and pass the appropriate parameters to a spherical_warp statement. This
> is the same as your tiling solution without the overhead of an image tiled in a
> paint program.
>
> You might also care to peruse the IRTC as I know there are at least two images
> that recently used imaged mapped skies with fairly stunning results. Perhaps
> comparing notes with their creators could lead to more satisfactory results for
> you.
>
> --
> --
> Batronyx ^"^
> bat### [at] cadronhsacom //old & going away
> bat### [at] alliancecablenet new & active now.
> http://www.batronyx.com

Post a reply to this message

"David Wallace" <dar### [at] earthlinknet> wrote in message
news:3BC747EA.81E07357@earthlink.net...
> I can transfer an image_map to a radial pigment using pigment_map:
>
[snip]

I received this in my mail before reading it here. But for everyone's sake:

It seems I was unintentionally misleading; radial didn't work like I remembered.
Probably, because I don't really recall using it with image_maps before,
however, I think it could if done with pigment functions.

Everything I said about spherical warps is correct though. With a little bit of
trial and error I came up with the code below. The image_map I used for the sky
came from Jeremy Engleman's website (as recommended by Gilles Tran).

http://art.net/~jeremy/photo/public_texture/index.html

They are sufficiently huge to avoid stretching. I cropped the ground out of the
bottom before saving as .bmp and naming it something more meaningful to me.

If you remove the water plane, change the initial x scaling of the pigment, or
its y rotation on the sky_sphere, (and had the bitmap) you would see where the
tiling occurs since I didn't bother to process the image for seamless tiling.

<code>
#version 3.5;
#include "colors.inc"
camera { location < -329,121.5 , 41.7> look_at < -600, 82.0 ,  0.0>
        angle 60}

#declare Sky1 = pigment { image_map { sys "PinkSunset.bmp" interpolate 2 }
     scale <1/5,0.25,1>
       }

#declare Sky2 = pigment { color SkyBlue}

sky_sphere {
      pigment {  Sky1
          warp{
               spherical
                    orientation z
                    dist_exp 1
          }
      rotate y* -8
      }
}/**/

plane {y, 0
     texture {
          pigment{color rgb<-1,-1,-1> }
          normal {wrinkles 0.1 scale 100}
          finish {
               ambient 0.1
               diffuse 0.6
               brilliance 1.0
               reflection { 1.0 }
          }

     }
}
</code>

Post a reply to this message