MegaPov 0.4 is ready for downloading. 

You can find Nathan's Windows version at (this is not the usual place!):
ftp://ftp.povray.org/pub/povray/Unofficial/MegaPOV/

The Macintosh version at the usual site:
http://users.skynet.be/smellenbergh

Please note that the demos are not available yet, we will make a small package
available later today
or tomorrow.
Please read the docs because there are quite a few changes in the syntax.

Bug fixes in this version: 
   *Faster macro's (by Burton Radons). 
   *Photons has an easier syntax now. 
   *Changed syntax of bounded_by and clipped_by in isosurface. 
   *Fixed the normal bugfix once more . 
   *Fixed default{} bug. 
   *Faster rendering of mesh and mesh2. 
   *Fixed bug with metallic. 
   *Updated statistics output for photons, motion_blur, and post-processing. 

New in this version: 
   *Blinn "microfacet" highlights . 
   *Post processing (focal_blur, depth, soft_glow) is now possible with MegaPov. 
   *Changes in radiosity (load/save file, pretrace_start/end). 
   *Changed 'smooth_color_triangle' syntax for more versatile triangle texture
interpolation. 
   *Chris Huff's blob pattern, proximity pattern, evaluate pigment/pattern, noise3d. 
   *Array support for integrated i_dat_3d libraries by David Sharp. 
   *Added hyperbolic trig functions, complex functions (David Sharp). 
   *Added ridgedmf, heteromf, hex_x and hex_y to the integrated isosurface functions. 
   *Added date, timer and tick functions to be used in in the scene source. 
   *Added wavelength-dependance to fresnel reflectivity (uses dispersion properties,
for producing
realistic metals). 

Greatings from Nathan on the road to sunshine and Smellenbergh*2 looking at the rain
:-)

-- 
e-mail:sme### [at] skynetbe

http://users.skynet.be/smellenbergh

Post a reply to this message

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.

-- 
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 <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