This "problem" is very simple and easy to reproduce, so I will not waste
bandwidth posting examples and images.

I am guessing this problem WILL NOT (hopefully) exist in POVRay 3.7+ (I am using
3.6.1 64 bit) (64 bit OS). The guess is due to something that Alain observed,
and comments by some others in another thread or two, and my assumption that
THIS problem is related to ANOTHER problem that I posted on.

Almost every example of media that I have seen involves defining a media
container such as:

box { 0,1 pigment {rgbt 1} hollow
   (... media with DF3)
 translate -0.5
}

(... or a sphere { 0,1 etc.)

I used a small 10 x 10 x 10 DF3 file, it is completely filled with value 255
($FF) voxels. If simple emission is used, it is a "big white cube of glowing
gas". (or absorption with a background, "big box of smoke"; or scattering, "big
box of fog").

This defines a media cube of 1 unit, at x=y=z=0 to x=y=z=1, and then translates
it such that the center of the cube is at the origin.

It renders OK.

BUT if I define the container as:

box { <-0.5,-0.5,-0.5>,<0.5,0.5,0.5> {rgbt 1} hollow
   (... media with DF3)
}

.... with no translation, in other words define the 1 unit box as already being
at the origin, then something very strange happens.

Only the PART of the media showing in the +X +Y +Z quadrant shows. That would be
the "uppermost northeast corner", the quadrant in +x +y +z.

ALL parts that are "BEHIND the origin" do NOT show, such that "only 1/8th" of
the media is showing.

This only happens with a DF3. If I just simply fill the box (at
<-0.5,-0.5,-0.5>,<0.5,0.5,0.5>) with simple media (whether emission, absorption
or scattering), it looks OK.

Post a reply to this message

JeffBTX <nomail@nomail> wrote:
> Only the PART of the media showing in the +X +Y +Z quadrant shows. That would be
> the "uppermost northeast corner", the quadrant in +x +y +z.

  There's nothing strange about that. Your media definition is a box in
the range <0,0,0>-<1,1,1>. Defining the container somewhere else is not
going to change that fact. The media is still inside <0,0,0>-<1,1,1>.

  If you want to translate the media *with* its container, you have to
translate *both*, not just the container. In other words:

box
{ 0, 1
  media { your df3 media }
  translate -.5
}

  Now it will work.

-- 
                                                          - Warp

Post a reply to this message

"JeffBTX" <nomail@nomail> wrote:
> BUT if I define the container as:
>
> box { <-0.5,-0.5,-0.5>,<0.5,0.5,0.5> {rgbt 1} hollow
>    (... media with DF3)
> }
>
> .... with no translation, in other words define the 1 unit box as already being
> at the origin, then something very strange happens.

This is for the simple reason that DF3 media does *not* repeat (I guess applying
some suitable repeat-warp would do the trick), nor does it "auto-center" on the
container: It always fills just the unit cube from <0,0,0> to <1,1,1>, and
everything outside is assumed to have the value 0 (even if all voxels in the
DF3 happen to be set to 1.0).

If you specify the box to match the unit cube, specify the media, and *then*
translate the whole smash, the translation will be applied to the media as
well, i.e. "dragging" it with the box, so to speak.


No bug here, and hence not "fixed" in 3.7 either.

Though admittedly it might be worth considering to have DF3 repeat by default,
like with image maps, and instead require the "once" keyword for non-repeating
operation.

Post a reply to this message

"clipka" <nomail@nomail> wrote:
> "JeffBTX" <nomail@nomail> wrote:
> > BUT if I define the container as:
> >
> > box { <-0.5,-0.5,-0.5>,<0.5,0.5,0.5> {rgbt 1} hollow
> >    (... media with DF3)
> > }
> >
> > .... with no translation, in other words define the 1 unit box as already being
> > at the origin, then something very strange happens.
>
> This is for the simple reason that DF3 media does *not* repeat (I guess applying
> some suitable repeat-warp would do the trick), nor does it "auto-center" on the
> container: It always fills just the unit cube from <0,0,0> to <1,1,1>, and
> everything outside is assumed to have the value 0 (even if all voxels in the
> DF3 happen to be set to 1.0).
>
> If you specify the box to match the unit cube, specify the media, and *then*
> translate the whole smash, the translation will be applied to the media as
> well, i.e. "dragging" it with the box, so to speak.
>
>
> No bug here, and hence not "fixed" in 3.7 either.
>
> Though admittedly it might be worth considering to have DF3 repeat by default,
> like with image maps, and instead require the "once" keyword for non-repeating
> operation.

Clipka;
Thank you for your reply. That makes sense to me, and I understand your input.
So basically, whenever using DF3s (if nothing else just to simply things); one
MUST use and visualize unit cubes from 0 to 1. THEN translate to wherever.

The main thing is that I understand your explanation for "why"; thank you.

Warp;
You read too fast.
:p
That is, you read my post too fast.
;p
Less coffee
:o

Specifying the cube from 0 to 1 doesn't cause the "problem". Specifying from
-0.5 to +0.5 is what caused the unexpected results. Clipka pretty much answers
my question.

I very much appreciate the input from this newsgroup... it is a valuable
resource, especially from old-timers to new-bies. (Not that I'm a newbie... its
just that with me, raytracing has been an on-again off-again thing).

- Thanks, Both

Post a reply to this message

JeffBTX <nomail@nomail> wrote:
> Specifying the cube from 0 to 1 doesn't cause the "problem".

  I never said it does.

> Specifying from
> -0.5 to +0.5 is what caused the unexpected results.

  Which is what I said.

-- 
                                                          - Warp

Post a reply to this message