In article <38947d50@news.povray.org>, Nieminen Juha 
<war### [at] punarastascstutfi> wrote:

>   The new features are amazing, as usual... :)
> 
>   I have a question about the trace function (perhaps this is not the 
>   correct
> thread for this, but I'm too lazy to write a separate article...):
>   The documentation says:
> 
> "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."
> 
>   What if I really want the perturbed normal? I can think of some uses of
> this.
>   Perhaps a 5th parameter (of boolen type) could be added? If the 
>   parameter
> is true, then the returned normal is perturbed by the texture before
> returning. The default value could be false.


How about adding a "perturb_normal()" function instead?

-- 
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/

Post a reply to this message

Chris Huff <chr### [at] yahoocom> wrote:
: How about adding a "perturb_normal()" function instead?

  It may be one solution, but difficult to use if the object in question
has complex transformations (you would have to apply the same transformations
to the texture before calling perturb_normal()).

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

In article <38948214@news.povray.org>, Nieminen Juha 
<war### [at] punarastascstutfi> wrote:

> Chris Huff <chr### [at] yahoocom> wrote:
> : How about adding a "perturb_normal()" function instead?
> 
>   It may be one solution, but difficult to use if the object in question
> has complex transformations (you would have to apply the same 
> transformations
> to the texture before calling perturb_normal()).


How about also adding a way to access the texture of the object? That 
way you could trace against the object, then use the object's texture 
normal(which was transformed along with the object) to perturb the real 
normal. The normal could be accessed by either a dot 
operator(preferable, something like this: Obj.texture.normal), or by a 
function(less flexible syntax, more keywords, etc. Something like 
get_tex_normal(Obj)).

-- 
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/

Post a reply to this message

Maybe I forget something, but the 'reset-children' feature doesn't work even
after adding the #version etc. line. What do I do wrong??

--
Regards,
Sander


smellenbergh <sme### [at] skynetbe> schreef in berichtnieuws
1e589wt.1fbph7bq1ekdqN%smellenbergh@skynet.be...
> MegaPov 0.4 is ready for downloading.

Post a reply to this message

Sander wrote:
> 
> Maybe I forget something, but the 'reset-children' feature doesn't work even
> after adding the #version etc. line. What do I do wrong??

Did you by any chance check it against the code Ron Parker recently
posted in povray.text.scene-files ? That code is known to work with
earlier versions.

    Subject:  Re: Brick wall and paving stones macros (~80kb)
       Date:  19 Jan 2000 10:15:35 -0500
       From:  ron### [at] povrayorg (Ron Parker)
 Newsgroups:  povray.binaries.images, povray.text.scene-files
 Followup-To: povray.text.scene-files
  References: 1 , 2 , 3 , 4



-- 
Ken Tyler -  1300+ Povray, Graphics, 3D Rendering, and Raytracing Links:
http://home.pacbell.net/tylereng/index.html http://www.povray.org/links/

Post a reply to this message

No I didn't. Not that I know what code you have in mind: but I will look
first. Thanks!

--
Regards,
Sander


Ken <tyl### [at] pacbellnet> schreef in berichtnieuws
3894ABB8.FA864E23@pacbell.net...
> Did you by any chance check it against the code Ron Parker recently
> posted in povray.text.scene-files ? That code is known to work with
> earlier versions.
>
>     Subject:  Re: Brick wall and paving stones macros (~80kb)
>        Date:  19 Jan 2000 10:15:35 -0500
>        From:  ron### [at] povrayorg (Ron Parker)
>  Newsgroups:  povray.binaries.images, povray.text.scene-files
>  Followup-To: povray.text.scene-files
>   References: 1 , 2 , 3 , 4

Post a reply to this message

On 30 Jan 2000 13:05:04 -0500, Nieminen Juha wrote:
>"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."
>
>  What if I really want the perturbed normal? I can think of some uses of
>this.

The main problem, if I recall correctly, is that the object may or may
not have a normal pattern applied to it at that point in parsing, since
it was #declared but not actually instantiated.  I could certainly check
if it does have one applied and if so do the extra calculations to perturb
the normal; it's just not something that occurred to me at the time.  I'm
not even sure you need the fifth boolean parameter: if you don't want
the perturbed normal, don't perturb it.

Post a reply to this message

Sander wrote:
> 
> Maybe I forget something, but the 'reset-children' feature doesn't work even
> after adding the #version etc. line. What do I do wrong??

Do you by chance have the warp listed in an include file? 
I have a work in progress that uses reset_children and it
conked out until I put the #version line at the top of the
inc file that actually contained the warp. Even once I
put it in the texture inc file, it still didn't work properly
until I also added the #version to the scene file where the 
#declared texture was actually referenced. It's much more 
restrictive than it was, but it still works...with a
little more typing <g>.

Charles

Post a reply to this message

While I'm on the subject, I'll mention here for the benefit of
anyone else who doesn't bother putting Version=3.1 in their INI 
files (like me, duh!), if you don't tell MegaPOV anything going 
in, it apparently automatically sets itself for version 3.00 which
of course kills the #macro directive. 

For some reason, setting ...

#version unofficial MegaPov 0.4;"

...won't change this behaviour even though setting...

"#version official 3.1;" 

..will fix it. (??) Anyway, the best solution is fix your 
INI files, I guess, but another workaround is to use
"#version official 3.1;" before you define your macros, then 
"#version unofficial MegaPov 0.4;" after you're finished. 
For whatever reasons, once they're defined, the version 
doesn't have any affect on the macros performance. Personally
I don't see why any version switch should turn off macros.
I mean, obviously macros didn't always exist and older
versions of POV won't handle them, but if the program
version you're using knows what they are, why be fussy and 
shut down with an error messgae because of a version switch?

Anyway, thought I'd post this observation in case it affects 
anyone else as dumb as me.

Charles

Post a reply to this message

I have used the #macro statement without any problem.
I did have to set  #version unofficial MegaPov 0.4; to
get isosurfaces to work, but that was all.
I am using WinMeagPov0.4. Are you on a different os?

Charles Fusner wrote:
> 
> While I'm on the subject, I'll mention here for the benefit of
> anyone else who doesn't bother putting Version=3.1 in their INI
> files (like me, duh!), if you don't tell MegaPOV anything going
> in, it apparently automatically sets itself for version 3.00 which
> of course kills the #macro directive.
> 
> For some reason, setting ...
> 
> #version unofficial MegaPov 0.4;"
> 
> ...won't change this behaviour even though setting...
> 
> "#version official 3.1;"
> 
> ..will fix it. (??) Anyway, the best solution is fix your
> INI files, I guess, but another workaround is to use
> "#version official 3.1;" before you define your macros, then
> "#version unofficial MegaPov 0.4;" after you're finished.
> For whatever reasons, once they're defined, the version
> doesn't have any affect on the macros performance. Personally
> I don't see why any version switch should turn off macros.
> I mean, obviously macros didn't always exist and older
> versions of POV won't handle them, but if the program
> version you're using knows what they are, why be fussy and
> shut down with an error messgae because of a version switch?
> 
> Anyway, thought I'd post this observation in case it affects
> anyone else as dumb as me.
> 
> Charles

-- 
Mr. Art

"Often the appearance of reality is more important 
than the reality of the appearance."
Bill DeWitt 2000

Post a reply to this message