POV-Ray : Newsgroups : povray.newusers : Access to height field data Server Time
28 Jul 2024 18:25:02 EDT (-0400)
  Access to height field data (Message 11 to 20 of 20)  
<<< Previous 10 Messages Goto Initial 10 Messages
From: gregjohn
Subject: Re: Access to height field data
Date: 3 Sep 2008 13:10:01
Message: <web.48bec46ecd5c214340d56c170@news.povray.org>
"Phil" <nomail@nomail> wrote:
>
> #define norm = <0,0,0>;

// Should that be:
#declare norm = <0,0,0>;

>
> #while (IN A REGION WE WANT TO PLANT)
>   #declare h = trace(map, <x,y,2>, <x,y,0>, norm);
>   #if ((vlength(norm) != 0) & (vlength(h) < 0.5))
>     object {
>       tree
>       translate h
>     }
>   #end

//  And then be sure to reset the norm back to
//  zero at before the next time you use it:

#declare norm = <0,0,0>;

> #end
>


Post a reply to this message

From: Kenneth
Subject: Re: Access to height field data
Date: 14 Oct 2008 01:50:00
Message: <web.48f430e7cd5c214378dcad930@news.povray.org>
"gregjohn" <pte### [at] yahoocom> wrote:

>   And then be sure to reset the norm back to
>   zero at before the next time you use it:
>
> #declare norm = <0,0,0>;
>
> > #end
> >

I don't think that's necessary (I've never found it to be.) norm just needs to
be 'created' once--as kind of an empty placeholder for the normal vector(s) that
will be found by tracing. (It can be set up with *any* three values, actually.)
Then each time trace traces the object, norm will be filled with a REAL normal
vector. No need to 'empty it out' each time.

Ken W.


Post a reply to this message

From: jan dvorak
Subject: Re: Access to height field data
Date: 14 Oct 2008 11:00:12
Message: <48f4b3fc$1@news.povray.org>
Kenneth napsal(a):
> "gregjohn" <pte### [at] yahoocom> wrote:
> 
>>   And then be sure to reset the norm back to
>>   zero at before the next time you use it:
>>
>> #declare norm = <0,0,0>;
>>
>>> #end
>>>
> 
> I don't think that's necessary (I've never found it to be.) norm just needs to
> be 'created' once--as kind of an empty placeholder for the normal vector(s) that
> will be found by tracing. (It can be set up with *any* three values, actually.)
> Then each time trace traces the object, norm will be filled with a REAL normal
> vector. No need to 'empty it out' each time.
> 
What if the trace misses the object?


Post a reply to this message

From: Warp
Subject: Re: Access to height field data
Date: 14 Oct 2008 11:50:09
Message: <48f4bfb1@news.povray.org>
jan dvorak <jan### [at] centrumcz> wrote:
> What if the trace misses the object?

  The returned normal vector will be zero.

-- 
                                                          - Warp


Post a reply to this message

From: Kenneth
Subject: Re: Access to height field data
Date: 15 Oct 2008 00:40:00
Message: <web.48f57244cd5c214378dcad930@news.povray.org>
Warp <war### [at] tagpovrayorg> wrote:
> jan dvorak <jan### [at] centrumcz> wrote:
> > What if the trace misses the object?
>
>   The returned normal vector will be zero.
>
> --
>                                                           - Warp

.......and your traced-on object will be placed at <0,0,0> by default. Without
some kind of 'escape' mechanism, you might end up with *lots* of objects there.
The standard way to keep that from happening is to do this before actually
making or calling an object:

#if(vlength(norm) != 0) // that's "not equal to zero"
object{my_object translate <...the traced location...>}
#else
// DON'T make an object
#end

If the trace 'ray' goes off your height_field (or whatever), norm will be
<0,0,0> -- and vlength of that will be zero. Very handy!

KW


Post a reply to this message

From: Alain
Subject: Re: Access to height field data
Date: 18 Oct 2008 11:14:41
Message: <48f9fd61$1@news.povray.org>
Kenneth nous illumina en ce 2008-10-15 00:35 -->
> Warp <war### [at] tagpovrayorg> wrote:
>> jan dvorak <jan### [at] centrumcz> wrote:
>>> What if the trace misses the object?
>>   The returned normal vector will be zero.
>>
>> --
>>                                                           - Warp
> 
> .......and your traced-on object will be placed at <0,0,0> by default. Without
> some kind of 'escape' mechanism, you might end up with *lots* of objects there.
> The standard way to keep that from happening is to do this before actually
> making or calling an object:
> 
> #if(vlength(norm) != 0) // that's "not equal to zero"
> object{my_object translate <...the traced location...>}
> #else
> // DON'T make an object
> #end
> 
> If the trace 'ray' goes off your height_field (or whatever), norm will be
> <0,0,0> -- and vlength of that will be zero. Very handy!
> 
> KW
> 
> 
> 
> 
> 
> 
> I prefer to simply use:
#if(vlength(Norm))
...
#end

Any non-zero value evaluate as true.
No need for the empty #else.

-- 
Alain
-------------------------------------------------
To the world you may be one person, but to one person you may be the world.


Post a reply to this message

From: William Tracy
Subject: Re: Access to height field data
Date: 19 Oct 2008 13:28:47
Message: <48fb6e4f@news.povray.org>
Alain wrote:
>> I prefer to simply use:
> #if(vlength(Norm))
> ...
> #end
> 
> Any non-zero value evaluate as true.

I find that slightly less readable; making the not-equal-zero explicit 
makes it clearer what you are trying to do.

If I wrote code like that on the job, my boss would be unhappy. ;-)

> No need for the empty #else.

I concur there.

-- 
William Tracy
afi### [at] gmailcom -- wtr### [at] calpolyedu

segfault_message = g_strdup(
     "Hi, user.  We need to talk.\n"
     "I think something's gone wrong here.  It's probably my fault.\n"
     "No, really, it's not you... it's me... no no no, I think we get 
along well\n"
     "it's just that.... well, I want to see other people.  I... what?!? 
  NO!  I \n"
     "haven't been cheating on you!!  How many times do you want me to 
tell you?!  And\n"
     "for the last time, it's just a rash!\n"
);
     -- from the Pidgin source code


Post a reply to this message

From: Alain
Subject: Re: Access to height field data
Date: 19 Oct 2008 17:37:46
Message: <48fba8aa$1@news.povray.org>
William Tracy nous illumina en ce 2008-10-19 13:28 -->
> Alain wrote:
>>> I prefer to simply use:
>> #if(vlength(Norm))
>> ...
>> #end
>>
>> Any non-zero value evaluate as true.
> 
> I find that slightly less readable; making the not-equal-zero explicit 
> makes it clearer what you are trying to do.
> 
> If I wrote code like that on the job, my boss would be unhappy. ;-)
> 
>> No need for the empty #else.
> 
> I concur there.
> 
When I had some programming courses, the teachers always told us that it was 
VERY BAD practice to test for a negated comparaison.

To write "if(x != 0)" or "if(x <> 0)", depending on the language used, was a 
sure way of failing. Instead, it was MANDATORY to use "if(x)". (x!>y) had to be 
replaces by (x<=y) whenever possible to. And (x !>= y) was an heresy!

-- 
Alain
-------------------------------------------------
After any salary raise, you will have less money at the end of the month than 
you did before.


Post a reply to this message

From: Kenneth
Subject: Re: Access to height field data
Date: 19 Oct 2008 18:50:00
Message: <web.48fbb795cd5c214378dcad930@news.povray.org>
William Tracy <wtr### [at] calpolyedu> wrote:
> Alain wrote:

> > No need for the empty #else.
>
> I concur there.
>

Me too--and less typing. :-)

I didn't want to confuse new users, though; I think that learning and using the
full syntax first gives newbies the confidence and experience to 'optimize'
their code later. It did for me. (Many times, in complex scenes, I still leave
complete syntax in, so that I don't have to hunt around for code snippets that
I've forgotten to add.)

KW


Post a reply to this message

From: Kenneth
Subject: Re: Access to height field data
Date: 19 Oct 2008 19:05:00
Message: <web.48fbbc40cd5c214378dcad930@news.povray.org>
Alain <ele### [at] netscapenet> wrote:

> When I had some programming courses, the teachers always told us that it was
> VERY BAD practice to test for a negated comparaison.
>
> To write "if(x != 0)" or "if(x <> 0)", depending on the language used, was a
> sure way of failing. Instead, it was MANDATORY to use "if(x)". (x!>y) had to be
> replaces by (x<=y) whenever possible to. And (x !>= y) was an heresy!
>

Interesting!

The only programming courses I've ever taken were back in the 'pre-history' days
of computing--writing Fortran IV on punched cards!  (Which *really* dates me,
eh?) I could very well have been taught the same do's and don'ts--but I've
sadly forgotten.

But back to POV: If I had written the POV 'escape' code like this...

#if(vlength(norm) = 0)
// don't make an object
#else
object{my_object translate <...the traced-on location...>}
#end

....it somehow doesn't 'look' right to me--sort of like telling POV NOT to make
any objects 'unless...'

An interesting little psychological difference. :-)

KW


Post a reply to this message

<<< Previous 10 Messages Goto Initial 10 Messages

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