POV-Ray : Newsgroups : povray.binaries.images : using the CUBIC pattern with image_maps : Re: using the CUBIC pattern with image_maps Server Time
4 May 2024 12:18:28 EDT (-0400)
  Re: using the CUBIC pattern with image_maps  
From: Kenneth
Date: 31 Dec 2017 19:40:00
Message: <web.5a49819f1231bd0289df8d30@news.povray.org>
> > 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

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.