>>   Some basic vector math knowledge could be of great help when designing
>> thing with POV-Ray... :P
>
> In my defence, I am relatively new and to me, a "vector" is a *direction*
> (which could be defined in various ways).  Yet what is returned is
> obviously three float values combined in what POV calls a "vector".
>
> Therefore, the normal vector could define a point 1 unit (or more?) away
> from the intersected point in the perpendicular direction, or could be 
> that
> point minus the intersected point.  So I suppose my real question is: How
> exactly does POV define its vectors?

In POV vectors are directions from the origin. This can be used to represent
a point <x,y,z> by the magnitude of the vector, or in some cases the 
magnitude
is ignored and the vector only represents a direction. For example, the 
normal
returned from the trace function represents the direction of the vector 
perpendicular
to the surface as a unit vector from the origin. (A unit vector has a length 
of 1 unit)
The vnormalize function returns a unit vector from a non-unit vector by 
changing the
vector length to one without changing the direction. Essentially, POV uses 
vectors
to represent points, because points ARE vectors, but uses unit vectors for 
directions.

To complicate matters a bit more, POV also uses vectors to define colors, so 
there
are options for two more vector components filter and transmit, making a 5D 
vector.
For clarity of use the dot x, dot y, and dot z accessors can be used as dot 
red,
dot green, and dot blue; so N.x = N.red, N.y = N.green, and N.z = N.blue.
The other 2 components can be accessed with dot filter, and dot transmit.

Addtionally you can use dot u and dot v for 2D vectors. So N.x = N.u, and
N.y = N.v. Also 4D vectors <x,y,z,t>, where N.t = N.filter.

Post a reply to this message

Kirk Andrews nous apporta ses lumieres en ce 12-12-2006 12:23:
> Thank you, that was very helpful--

>>   Some basic vector math knowledge could be of great help when designing
>> thing with POV-Ray... :P

> In my defence, I am relatively new and to me, a "vector" is a *direction*
> (which could be defined in various ways).  Yet what is returned is
> obviously three float values combined in what POV calls a "vector".

> Therefore, the normal vector could define a point 1 unit (or more?) away
> from the intersected point in the perpendicular direction, or could be that
> point minus the intersected point.  So I suppose my real question is: How
> exactly does POV define its vectors?

> In any case, you've certainly answered my current problem and I appreciate
> your patience with my ignorance.

> Kirk

In fact, a vertor is a direction PLUS a distance. It can be defined as 3 angles 
and a distance, OR as the end point's coordinates relative to it's starting point.
In 2D, it's an angle plus a lenght or the 2D coordinates of the tip relative to 
the start.
A normalised vector is a vector witch is 1 unit in lenght. Normaly, the normal 
vector returned by the trace function is such a vector.

-- 
Alain
-------------------------------------------------
Make yourself a better person and know who you are before you try and know 
someone else and expect them to know you.

Post a reply to this message

Alain wrote:
> In fact, a vertor is a direction PLUS a distance.

Technically, it's a direction PLUS a distance that's invariant under 
rotation or translation of the coordinate system in which it's embedded. 
:-) Otherwise, it's just a tuple.

-- 
   Darren New / San Diego, CA, USA (PST)
     Scruffitarianism - Where T-shirt, jeans,
     and a three-day beard are "Sunday Best."

Post a reply to this message

"Kirk Andrews" <kir### [at] hotmailcom> schreef in bericht 
news:web.457eb359aa33b1599033e1160@news.povray.org...
> I'm trying to use the trace command to plant grass on my Isosurface
> landscape, but I don't want it to "grow" on steep grades.  Is it possible
> to use the slope pattern to control my distribution, or is there another
> way to do this?
>

All the answers given so far are excellent, however, I think you need an 
example scene now to understand it fully (I did).
I shall post one today in p.b.s-f under the same header.

Thomas

Post a reply to this message

In fact, It is such a small piece of code, that I can post it here below.

Thomas

//=======================================================================================
// -------- Placing the trees -------------
#debug "Placing trees...\n"

#declare Spacing = 1;
#declare Cnt = 0;


#declare PosX = -15;

#while (PosX < 15)

  #declare PosZ = -25;

  #while (PosZ < 15)

    // trace function
    #declare Norm = <0, 0, 0>;
    #declare Start = <PosX+(rand(Seed)-0.5)*Spacing, 
UpperBound+Isoscale.y+1, PosZ+(rand(Seed2)-0.5)*Spacing>;
    #declare Pos = trace (
                          Landscape,       // object to test
                          Start,           // starting point
                          -y,              // direction
                          Norm );          // normal


    #if (Norm.x != 0 | Norm.y != 0 | Norm.z != 0)   // if intersection is 
found, normal differs from 0
      #if ((vdot(Norm, y)>0.5) & (Pos.y < 5.5))     // criteria for placing 
trees: not too steep and not too high
        object {
          //Tree (0.5+rand(Seed)*0.02)
          TREE
          scale RRand(1.0, 2.5, Seed)
          rotate RRand(0, 360, Seed2)*y
          translate Pos
        }
        #declare Cnt = Cnt+1;
      #end
    #end

    #declare PosZ = PosZ+Spacing;

  #end

  #declare PosX = PosX+Spacing;
#end
#debug concat("Placed ", str(Cnt,0,0), " Trees\n")

#end
//=======================================================================================

Post a reply to this message

Thomas de Groot <t.d### [at] internldotnet> wrote:
>     #if (Norm.x != 0 | Norm.y != 0 | Norm.z != 0)

  Btw, another way of testing that is:

  #if(vlength(Norm) > 0)

>       #if ((vdot(Norm, y)>0.5) & (Pos.y < 5.5))

  Does trace() always return a normalized vector?

-- 
                                                          - Warp

Post a reply to this message

"Warp" <war### [at] tagpovrayorg> schreef in bericht 
news:457fc925@news.povray.org...
> Thomas de Groot <t.d### [at] internldotnet> wrote:
>>     #if (Norm.x != 0 | Norm.y != 0 | Norm.z != 0)
>
>  Btw, another way of testing that is:
>
>  #if(vlength(Norm) > 0)

Ah, yes! that's neat!

>
>>       #if ((vdot(Norm, y)>0.5) & (Pos.y < 5.5))
>
>  Does trace() always return a normalized vector?
>

Yes, if you define also the fourth trace parameter (a vector), Norm in this 
case (see documentation 3.2.1.4.5). This works fine as far as I can tell. To 
tell the truth, I used this after an example from somebody else :-)  So, 
things are transmitted on. However, there might be an even better way to do 
this, but I have not investigated that far as this worked for me.

Thomas

Post a reply to this message

Thomas de Groot <t.d### [at] internldotnet> wrote:
> >  Does trace() always return a normalized vector?

> Yes, if you define also the fourth trace parameter (a vector), Norm in this 
> case (see documentation 3.2.1.4.5).

  There's no such section number in the current documentation
(http://povray.org/documentation/view/3.6.1/570/)

  As for the documentation on the trace() function (2.2.1.4.5), it does not
mention returning a normalized vector.

-- 
                                                          - Warp

Post a reply to this message

"Warp" <war### [at] tagpovrayorg> schreef in bericht 
news:458072c4@news.povray.org...
> Thomas de Groot <t.d### [at] internldotnet> wrote:
>> >  Does trace() always return a normalized vector?
>
>> Yes, if you define also the fourth trace parameter (a vector), Norm in 
>> this
>> case (see documentation 3.2.1.4.5).
>
>  There's no such section number in the current documentation
> (http://povray.org/documentation/view/3.6.1/570/)
>
>  As for the documentation on the trace() function (2.2.1.4.5), it does not
> mention returning a normalized vector.
>

Strange....
My documentation for version 3.6 is headed:   3.2.1.4.5  Functions
This is what it says about trace():
quote
trace(OBJECT_IDENTIFIER, A, B, [VECTOR_IDENTIFIER]). trace helps you finding 
the exact location of a ray intersecting with an object's surface. It traces 
a ray beginning at the point A in the direction specified by the vector B. 
If the ray hits the specified object, this function returns the coordinate 
where the ray intersected the object. If not, it returns <0,0,0>. If a 
fourth parameter in the form of a vector identifier is provided, the normal 
of the object at the intersection point (not including any normal 
perturbations due to textures) is stored into that vector. If no 
intersection was found, the normal vector is reset to <0,0,0>.
Note: Checking the normal vector for <0,0,0> is the only reliable way to 
determine whether an intersection has actually occurred, intersections can 
and do occur anywhere, including at <0,0,0>.

unquote

so.... what do you think?

Thomas

Post a reply to this message

Thomas de Groot nous apporta ses lumieres en ce 14-12-2006 04:03:
> "Warp" <war### [at] tagpovrayorg> schreef in bericht 
> news:458072c4@news.povray.org...
>> Thomas de Groot <t.d### [at] internldotnet> wrote:
>>>>  Does trace() always return a normalized vector?
>>> Yes, if you define also the fourth trace parameter (a vector), Norm in 
>>> this
>>> case (see documentation 3.2.1.4.5).
>>  There's no such section number in the current documentation
>> (http://povray.org/documentation/view/3.6.1/570/)

>>  As for the documentation on the trace() function (2.2.1.4.5), it does not
>> mention returning a normalized vector.


> Strange....
> My documentation for version 3.6 is headed:   3.2.1.4.5  Functions
> This is what it says about trace():
> quote
> trace(OBJECT_IDENTIFIER, A, B, [VECTOR_IDENTIFIER]). trace helps you finding 
> the exact location of a ray intersecting with an object's surface. It traces 
> a ray beginning at the point A in the direction specified by the vector B. 
> If the ray hits the specified object, this function returns the coordinate 
> where the ray intersected the object. If not, it returns <0,0,0>. If a 
> fourth parameter in the form of a vector identifier is provided, the normal 
> of the object at the intersection point (not including any normal 
> perturbations due to textures) is stored into that vector. If no 
> intersection was found, the normal vector is reset to <0,0,0>.
> Note: Checking the normal vector for <0,0,0> is the only reliable way to 
> determine whether an intersection has actually occurred, intersections can 
> and do occur anywhere, including at <0,0,0>.

> unquote

> so.... what do you think?

> Thomas




There is no mention of a normalised normal vector, it mention the normal vector.

-- 
Alain
-------------------------------------------------
A day for firm decisions!!!!!  Or is it?

Post a reply to this message