For my continuing work on my 'city buildings' scene, I wanted to check out the
new(?) CUBIC pattern, to see if might be an easier way to apply my
building-window image_maps to the five visible sides of a box.

The docs explain only the very basics of using the pattern, as a simple list of
six textures to apply. This works fine as-is for applying 'typical' pigments--
bozo, bumps, gradients, etc.-- but doesn't work well with individual image_maps
on the cube's faces. How to do that turned out to be not quite so obvious, so I
thought I would post the basic procedure.

There might be other permutations of scale/translate that would also work, but
these are what I came up with. (Ideally, the same scales/translations should
also be used with POV-Ray's other pigment patterns, but are probably unnecessary
because of the visual nature of those patterns. The placement of image_maps is
more finicky.)

[NOTE: DON'T use the 'once' keyword in the image_maps; it causes that particular
face of the cube to disappear! Which might actually be useful, of course.]
------------
box{0,1
   translate -.5 // box needs to be centered on origin, as docs say
   texture{
        cubic

   // RIGHT-SIDE
   texture{pigment{image_map{jpeg "CUBIC image 1.jpg"}
   rotate -90*y translate <0,.5,.5>}}

   // TOP
   texture{pigment{image_map{jpeg "CUBIC image 2.jpg"}
   rotate 90*x translate <.5,0,.5>}}

   // REAR
   texture{pigment{image_map{jpeg "CUBIC image 3.jpg"}
   scale -1 rotate 180*x translate <.5,.5,0>}}

   // LEFT_SIDE
   // texture{pigment{cells scale .15}}
   texture{pigment{image_map{jpeg "CUBIC image 4.jpg"}
   rotate 90*y translate <0,.5,.5>}}

   // BOTTOM
   texture{pigment{image_map{jpeg "CUBIC image 5.jpg"}
   rotate -90*x translate <.5,0,.5>}}

   // FRONT
   texture{pigment{image_map{jpeg "CUBIC image 6.jpg"}
   translate <.5,.5,0>}}
          }
    }

Post a reply to this message

Attachments:
Download 'cubic_pattern_good.jpg' (377 KB)

Preview of image 'cubic_pattern_good.jpg'

On 12/24/2017 10:26 AM, Kenneth wrote:
> For my continuing work on my 'city buildings' scene, I wanted to check out the
> new(?) CUBIC pattern, to see if might be an easier way to apply my
> building-window image_maps to the five visible sides of a box.
> 

Thanks for the information! On my list to try such a set up while 
creating my df3 cubic maps.

Bill P.

Post a reply to this message

William F Pokorny <ano### [at] anonymousorg> wrote:

>
> Thanks for the information! On my list to try such a set up while
> creating my df3 cubic maps.
>

The 'internal volume' of the textured cube is quite interesting, as I discovered
while doing some CSG-differencing tests. Each of the six cube faces is actually
a volumetric pyramid, with the apexs all meeting at the center of the cube. Kind
of strange, but logical. If I understand df3s, that would present a visual
problem.

But I'm working out a way around that oddity, essentially by substituting some
duplicated/reversed textures-- so that there are only THREE continuous
non-pyramidal volumetric textures throughout the cube, oriented in x,y and z.
That should solve the df3 problem (and my intended CSG use.) Working on it now;
will post the updated code asap.

Post a reply to this message

Attachments:
Download 'cubic_pattern_csg_test.jpg' (984 KB)

Preview of image 'cubic_pattern_csg_test.jpg'

> > William F Pokorny <ano### [at] anonymousorg> wrote:
> >
> > Thanks for the information! On my list to try such a set up while
> > creating my df3 cubic maps.
>
>  [Kenneth wrote...]
> Each of the six cube faces is actually
> a volumetric pyramid, with the apexs all meeting at the center of the cube.
> If I understand df3s, that would present a visual problem.
>
> But I'm working out a way around that oddity...so that there are only THREE
> continuous non-pyramidal volumetric textures throughout the cube, oriented
> in x,y and z.

Well, there are some features of this cubic pattern that I didn't grasp at
first.

The docs say that the unit box must initially be centered on the origin before
the six textures are applied. (Otherwise, the texture applications look strange
and unexpected.) The 'center apex' of the six texture 'pyramids' is AT the
origin, <0,0,0>-- but the 'bases' of the six  pyramids actually extend out to
infinity in their respective directions-- i.e., gigantic pyramids!  A unit box
just samples a tiny chunk of the pattern at the origin. But by  making the
initial  box like this for example...

box{ 0,1 translate -.5 translate 1*x...}

.....before the textures are applied,  you can move the box AWAY from the apex
into JUST texture #1's pyramid volume (the 'right-most' pyramid'). Then the box
will have only ONE texure applied all the way through it-- and the other five
textures are not even needed! Of course, the end result is the same as if you
never used the cubic pattern in the first place, and just applied an image_map
to a box in the usual way. Unfortunately, there's no place in space to move the
box to get *more* than one strictly x/y/z texture to fully 'blend together'
inside the box. That's just the nature of the 'isolated pyramids' scheme.  I
haven't completely given up on the idea, though...

I don't yet know how or if this cubic pattern could be used for MEDIA inside the
box. Or the use of df3 patterns.

Trying to use 'transmit .x' (or 'transmit all .x' for image_maps) to get partial
transparency of a  pigment/face doesn't seem to work at all.  Perhaps by design;
or maybe it was left out by mistake(?) But I think it would make only a face's
SURFACE semi-transparent-- which would not show the 'volumetric' nature of the
box's other five pyramidal pigments anyway, just an empty box.

I also found that the 'once' keyword *can* be used in the image_maps; the reason
it made a  face texture disappear was because my texture applications were in
the 'wrong  place' on some of the faces-- now fixed (see code below). Actually,
the 'once' behavior is only noticiable if you scale down an image_map; otherwise
it doesn't change the appearance on the box face.

In my initial code post, I also neglected to take SCALING of the image_maps into
account. I've since come up with better translations etc. to make this uniform--
each image_map now scales up from its lower left-hand corner, if you want to do
that. (The scaling point can be changed to the *center* of each face, BTW, with
some different translations.)

box{0,1
     translate -.5
     texture{
            cubic

   // RIGHT-SIDE
   texture{pigment{image_map{jpeg "CUBIC image 1.jpg"}
   rotate -90*y translate <0,-.5,-.5>}

   // TOP
   texture{pigment{image_map{jpeg "CUBIC image 2.jpg"}
   rotate 90*x translate <-.5,0,-.5>}

   // REAR
   texture{pigment{image_map{jpeg "CUBIC image 3.jpg"}
   scale <-1,1,1> translate <.5,-.5,0>}

   // LEFT_SIDE
   texture{pigment{image_map{jpeg "CUBIC image 4.jpg"}
   rotate 90*y translate <0,-.5,.5>}

   // BOTTOM
   texture{pigment{image_map{jpeg "CUBIC image 5.jpg"}
   rotate -90*x translate <-.5,0,.5>}

   // FRONT
   texture{pigment{image_map{jpeg "CUBIC image 6.jpg"}
   translate <-.5,-.5,0>}
         }
}

Post a reply to this message

On 12/31/2017 07:36 PM, Kenneth wrote:

Just getting back to this after getting side tracked.

> ...... Unfortunately, there's no place in space to move the
> box to get *more* than one strictly x/y/z texture to fully 'blend together'
> inside the box. That's just the nature of the 'isolated pyramids' scheme.  I
> haven't completely given up on the idea, though...

I'm perhaps missing your intent, but the cubic pattern does map the 3D 
space inside the +x,+y,+z,-x,-y and -z pyramids. Meaning if the textures 
in the texture list change/blend along the appropriate axis you can 
blend multiple textures or images inside each pyramid/face. For example 
something like:

#declare MapRed     = color_map { [ 0 White ] [ 1 Red ] }
#declare MapGreen   = color_map { [ 0 White ] [ 1 Green ] }
#declare MapBlue    = color_map { [ 0 White ] [ 1 Blue ] }
#declare MapYellow  = color_map { [ 0 White ] [ 1 Yellow ] }
#declare MapCyan    = color_map { [ 0 White ] [ 1 Cyan ] }
#declare MapMagenta = color_map { [ 0 White ] [ 1 Magenta ] }
#declare Pred     = pigment { gradient +x color_map { MapRed } }
#declare Pgreen   = pigment { gradient +y color_map { MapGreen } }
#declare Pblue    = pigment { gradient +z color_map { MapBlue } }
#declare Pyellow  = pigment { gradient -x color_map { MapYellow } }
#declare Pcyan    = pigment { gradient -y color_map { MapCyan } }
#declare Pmagenta = pigment { gradient -z color_map { MapMagenta } }
#declare PigmentCubic = pigment {
     cubic
     pigment { Pred }
     pigment { Pgreen }
     pigment { Pblue }
     pigment { Pyellow }
     pigment { Pcyan }
     pigment { Pmagenta }
}

See the attached image where the cylinders use PigmentCubic at the 
origin and the boxes (scale -1 inverted boxes to the left) were textured 
at differing start sizes then scaled to a normalized size.

If your initial box centered at the origin is say 0.1 on a side it will 
be near white on all sides. If near 2 on a side, each face will be near 
the '1' color in the corresponding color map. To do something like this 
with multiple images per face, you use a pigment_map instead of a color 
map. Pick which 'image' by your initial box size within the cubic 
pattern and size afterward to need.

> 
> I don't yet know how or if this cubic pattern could be used for MEDIA inside the
> box. Or the use of df3 patterns.

I'm not looking to use such a result directly, but rather to create df3s 
from images created via the use of the cubic pattern. In other words I'm 
looking to use the cubic pattern to set up to render a cubic map image I 
can convert to a df3 file to use with warp { cubic }.

> 
> Trying to use 'transmit .x' (or 'transmit all .x' for image_maps) to get partial
> transparency of a  pigment/face doesn't seem to work at all.  Perhaps by design;
> or maybe it was left out by mistake(?) But I think it would make only a face's
> SURFACE semi-transparent-- which would not show the 'volumetric' nature of the
> box's other five pyramidal pigments anyway, just an empty box.
> 
> 

I've used the alpha channel transparency in png files to see through 
parts of the faces to the inside surface of opposing faces. I thought 
the transmit <n/all> and filter <n/all> were for use with indexed image 
file formats like gif, but perhaps I'm not up with current functionality?

Bill P.

Post a reply to this message

Attachments:
Download 'the.png' (42 KB)

Preview of image 'the.png'

William F Pokorny <ano### [at] anonymousorg> wrote:

>
> I'm perhaps missing your intent, but the cubic pattern does map the 3D
> space inside the +x,+y,+z,-x,-y and -z pyramids. Meaning if the textures
> in the texture list change/blend along the appropriate axis you can
> blend multiple textures or images inside each pyramid/face. For example
> something like:
[snip]

Yes, that's the idea that I had in mind-- and it looks like you've solved it! I
need to digest your idea further, to fully understand it. Nicely done. And
thanks for posting your image example.

>
> I've used the alpha channel transparency in png files to see through
> parts of the faces to the inside surface of opposing faces. I thought
> the transmit <n/all> and filter <n/all> were for use with indexed image
> file formats like gif, but perhaps I'm not up with current functionality?
>

I actually haven't tried applying an alpha-channel image_map to one of the
faces; I should do that, to see the results.

'transmit all ..some value..' can be used with an image_map, to make it
semi-transparent or even to fade it out completely. It works with JPEG and PNG
images, although I haven't tried other types. (I'm not too familiar with indexed
images or how POV-ray handles them.)  A recent fix by Clipka even allows
*alpha-channel* images to be likewise faded, even though they already have an
alpha-channel mask (a feature that was 'broken' for a long time.)

Post a reply to this message

It occurs to me that there is another major use for this cubic pattern: as a
'cubic' environnment map. (Maybe that was the original reason for its creation?)

Fot distant environmment maps that envelop a scene--as for radiosity use or
reflections-- I always use a sphere or hemisphere as the object, with a texture
or suitable photograph on it. But 'cubic'-shaped maps can also be used. (I've
never worked with computer games or GPU processing, but it looks like cubic maps
are the main technique used there, not spherical maps.) One of the reasons seems
to be that a cubic map makes better use of the texture's pixels-- less
distortion when mapping the original texture onto the cube faces vs. the inner
surface of a sphere.

I came across an old Paul Bourke article that explains it better...

http://paulbourke.net/miscellaneous/cubemaps/

Post a reply to this message

On 20/01/2018 17:37, Kenneth wrote:
> It occurs to me that there is another major use for this cubic pattern: as a
> 'cubic' environnment map. (Maybe that was the original reason for its creation?)
> 
> Fot distant environmment maps that envelop a scene--as for radiosity use or
> reflections-- I always use a sphere or hemisphere as the object, with a texture
> or suitable photograph on it. But 'cubic'-shaped maps can also be used. (I've
> never worked with computer games or GPU processing, but it looks like cubic maps
> are the main technique used there, not spherical maps.) One of the reasons seems
> to be that a cubic map makes better use of the texture's pixels-- less
> distortion when mapping the original texture onto the cube faces vs. the inner
> surface of a sphere.
> 
> I came across an old Paul Bourke article that explains it better...
> 
> http://paulbourke.net/miscellaneous/cubemaps/
> 
> 
> 
> 

Worked out from first principles. Impressive. :-)

Have a look at this site.
http://www.pauldebevec.com/Probes/

And scroll down to:
Probes in the Vertical Cross Cube Format



-- 

Regards
     Stephen

Post a reply to this message

http://www.f-lohmueller.de/pov_tut/backgrnd/p_sky9.htm

Post a reply to this message

"Bald Eagle" <cre### [at] netscapenet> wrote:
> http://www.f-lohmueller.de/pov_tut/backgrnd/p_sky9.htm

Thanks; I hadn't seen that.

Post a reply to this message