"bubble_person" <nomail@nomail> wrote:
> Alain Martel <kua### [at] videotronca> wrote:

> > Note : Your area_light is oblique. If you want it to be flat, then, it's
> > size should be something like this :
> > area_light 160*x 200*z 65 65

> For the area_light, I was certainly not clear on the pov-ray documentation and
> examples.  From what I understand, I am creating a box (light box) that is
> parallel with the xy-plan, onto which I'm stretching an array of 100x100 light
> sources.


>
> I am, however, still confused on why the area_light would be tilted.  As you
> mentioned, I want a light parallel to the xy plane, and thought that this was
> the case.

I'm confused also.  I'm not entirely certain that using looks_like will tilt the
area light array.  (I'm not sure of the top of my head how to accurately
visualize the actual area light.)




> Given this example below, my understanding is that my light_box is a box that is
> 160x200x2 units (x,y,z) and collared white.  I then locate my light_source at
> <light_loc_x, light_loc_y,light_loc_z>.  I then use the area_light feature to
> define two points <-10, -10, 10>, <10, 10, 10> from the origin to indicate the
> vectors over which to stretch the light.
>
> #declare light_box = box{ <-80,-100,0>, <80,100,2>
>         pigment{color White}
>        } //end light box
> light_source {
>     <light_loc_x, light_loc_y,light_loc_z>
>     color White
>     area_light <-10, -10, 10>, <10, 10, 10>, 100, 100
>     adaptive 1
>     jitter
>     looks_like { light_box }
>   }

So, a few things, in no particular order or importance:

It's ... weird to be that you're making a box of one size and an area light of
another.  Use the same dimensions.

Also kinda clunky that you're defining location x, y, and z separately, when you
could just declare a vector.

Is your light box visible in the scene? (I can't see it)  If not, can you just
use  a light source without the looks_like attribute?

Just in case you didn't know, when x, y, and z are used outside of function {}
equation definitions, they refer to vectors  (<1, 0, 0>, etc.)
So you can do something like 10*x to get <10, 0, 0>

Also, we have a weird thing in POV-Ray called automatic vector promotion.  They
way it works is, say you are making your light box, and you need two 3D vectors.
 If you are making a unit cube centered at the origin, you can do something
like:
box {-0.5, 0.5}, and the automatic vector promotion will promote --- expand ---
the scalar quantities into the 3D vectors that POV-Ray's parser is expecting for
those parameters.
So what you'd wind up with is the equivalent of:
box {<-0.5, -0.5, -0.5>, <0.5, 0.5, 0.5>}

This can be convenient for certain things, and a real PITA with others (rgbft
color vectors)

I noticed that Kenneth tracked down your core issue - and you may want to try
modeling individual components separately, one by one, in a standalone scene so
that you can see exactly what is going on.  That would have shown you that your
spheres have the default texture, not the one you _thought_ you were using.

You're making a tube filled with stuff that will be in some rotated position.
Rather than rotating every individual component to line up with a rotated tube,
model your tube around the origin, place everything inside it, and then rotate
the whole union {} of everything all at once.

To save a million lines of code, declare your material, ONCE, and then use that
declared material name.

To save even more internal gymnastics, write a loop to make all of your spheres
inside of a union, and then apply that material to the entire union of spheres,
not to each individual sphere.

Think in a hierarchies and flowcharts.

Busy here doing other things and juggling crises, but looking forward to seeing
your progress and answering any questions when time allows.  :)

- Bill

Post a reply to this message