POV 3.1g + UVPov + SuperPatch + MultiPatch + new features = MegaPov

Go grab my latest compile (now called MegaPov).  Smellenbergh and Ron Parker
are also to be thanked for this, since this incorporates both the SuperPatch
and the Mac MultiPatch.  Also, Smellenbergh helped a LOT in merging the
MultiPatch into UVPov (he did almost all of the merging).

Anyway... I've also added per-object motion bluring (based on a Ron Parker
suggestion), persistent variables and persistent scene objects.

With all of these changes, there are likely to be bugs... so be on the
lookout for future updates.

http://nathan.kopp.com/patched.htm

-Nathan Kopp

Post a reply to this message

Nathan Kopp wrote:
> 
> POV 3.1g + UVPov + SuperPatch + MultiPatch + new features = MegaPov

Excellent news Nathan !

Question: Will Ron Parker be dropping the SuperPatch project now ?

-- 
Ken Tyler

Post a reply to this message

On Fri, 10 Dec 1999 00:04:05 -0500, "Nathan Kopp" <Nat### [at] Koppcom>
wrote:

>POV 3.1g + UVPov + SuperPatch + MultiPatch + new features = MegaPov
>
>Go grab my latest compile (now called MegaPov).

Done, installed. You made my day, Nathan!


Peter Popov
pet### [at] usanet
ICQ: 15002700

Post a reply to this message

I got it before I reached this group here.  Too bad I can't keep up and
use these nifty unofficial versions enough to satisfy myself before the next
one comes down the pike.  Appropriate icon there, that M is blazing from the
raytracing speed or haste in being the latest patch?  Maybe it subliminally
stands for Mars and that earlier spacecraft which burned up in the Martian
atmosphere  8^0  in which case we should also watch out for metric
conversion trouble.
  So I say in all jest: "Slow up!"  Though you can ignore that entirely if
you want to.

Bob

"Peter Popov" <pet### [at] usanet> wrote in message
news:Zp5QOD4wCF236TRVI4gWON=cB2Mu@4ax.com...
> On Fri, 10 Dec 1999 00:04:05 -0500, "Nathan Kopp" <Nat### [at] Koppcom>
> wrote:
>
> >POV 3.1g + UVPov + SuperPatch + MultiPatch + new features = MegaPov
> >
> >Go grab my latest compile (now called MegaPov).
>
> Done, installed. You made my day, Nathan!
>
>
> Peter Popov
> pet### [at] usanet
> ICQ: 15002700

Post a reply to this message

This is astonishing. What else can I say?

  I'm just trying to compile it in a SparcStation. There are //-comments which
are causing problems. Also the lack of a makefile causes some problems.
  I'll report when (or if) I have compiled it.

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

On Thu, 09 Dec 1999 21:15:37 -0800, Ken wrote:
>Question: Will Ron Parker be dropping the SuperPatch project now ?

I'm chasing Mick's bug at the moment, and I will continue to do so until
I catch it, but I am considering doing so, yes.

-- 
These are my opinions.  I do NOT speak for the POV-Team.
The superpatch: http://www2.fwi.com/~parkerr/superpatch/
My other stuff: http://www2.fwi.com/~parkerr/traces.html

Post a reply to this message

Ron Parker wrote:

> I'm chasing Mick's bug at the moment, and I will continue to do so until
> I catch it, but I am considering doing so, yes.

 Well I personaly have no problem with this as long as it means it frees
up more of your time to work on the official release of POV-Ray v 3.5.

-- 
Ken Tyler

Post a reply to this message

On Fri, 10 Dec 1999 05:51:03 -0800, Ken wrote:
>
>Ron Parker wrote:
>
>> I'm chasing Mick's bug at the moment, and I will continue to do so until
>> I catch it, but I am considering doing so, yes.
>
> Well I personaly have no problem with this as long as it means it frees
>up more of your time to work on the official release of POV-Ray v 3.5.

Well, yeah, that's one of my goals.  Also, Nathan seems to be better able 
to actually create a shipping product from a bunch of cool patches, whereas
I just sit around and tell y'all how cool the next one's gonna be without
ever taking the time to write the documentation and put it online.

-- 
These are my opinions.  I do NOT speak for the POV-Team.
The superpatch: http://www2.fwi.com/~parkerr/superpatch/
My other stuff: http://www2.fwi.com/~parkerr/traces.html

Post a reply to this message

> With all of these changes, there are likely to be bugs...
> so be on the lookout for future updates.

Mostly what I've tried with MegaPov seems to work great.

But trying parametric{function{}} object has so far given a
consistent Windows "Illegal operation" and aborting of
MegaPov  very quickly after hitting "Run". I would attempt
to collect and supply more information, but wanted to make
sure everybody was aware of this as soon as possible so
everyone could drop whatever they are doing so they can be
working round the clock to fix this.

Post a reply to this message

Ok, I compiled it in this SparcStation and it seems to work.
  The compilation was far from trivial, though. It could be nice if all those
//-comments were removed. They cause lots of problems.
  Also a makefile would be nice.

  There was an error point.c:

point.c:499: `false' undeclared (first use in this function)

  The fractal patterns seem to work.
  However I noticed that something weird happens with normals (as someone
else has already noticed). For example the following scene renders quite
weird and completely different from my original patch or the (fixed) uvpov 6.2.
The correct image can be seen in p.b.images (in a thread called "interesting
texture using the fractal patch" or something similar):

//-------------------------------------------------------------------------
camera { location -z*5 look_at 0 angle 35 }
light_source { <100,100,-20>, 1 }

box
{ <-2.5,-2,0><2.5,3.8,.1>
  pigment
  { magnet1m 30 color_map
    { [0 rgb <1,.7,.3>][.5 rgb <.8,.4,.1>][1 rgb <1,.7,.3>]
    }
    fractal_exterior_type 6,.001
    fractal_interior_type 1,200
    translate <-2,-1,0> scale 10
  }
  normal
  { magnet1m 30 1 slope_map
    { [0 <1,0>][1 <0,-1>]
    }
    fractal_interior_type 1,200
    translate <-2,-1,0> scale 10
  }
  finish { specular .5 }
  rotate x*60
}
//-------------------------------------------------------------------------


  I have not tried, but I suppose that this problem is not specific to
the fractal patterns. It just appeared first when I tried them.

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

I wrote
> But trying parametric{function{}} object has so far given a
> consistent Windows "Illegal operation" and aborting of
> MegaPov  very quickly after hitting "Run".
[ ... ]

The next snippet gives trouble
( "MegaPov attempted illegal operation"):
//////////////////////////////////////
#declare parametrictest=
    parametric
     {
       function
        f( u,v),
        g(u,v),
        h(u,v)
       <-6,-6>,<6,6>
     }
object{
     parametrictest
}
///////////////////////////////////

But not:

object{
     parametric
     {
       function
           f( u,v),
           g(u,v),
           h(u,v)
          <-6,-6>,<6,6>
}

And something about this sure seems familiar, from earlier
Superpatch use.

Post a reply to this message

Nathan Kopp wrote:

> With all of these changes, there are likely to be bugs

 Ken's Bug Log for MegaPov. I'll submit more as I find them but it is
likely to be much later today before I can work with the program more.


The following is a program crash related problem ---

//	Persistence of Vision Ray Tracer Scene Description File
//	File: trace_hf_pattern.pov
//	Date: 15/11/99
//	Demo showing the use of pattern and trace function.

This crash was repeatable and occured immediately after parsing and when
the display window appeared.


MEGAPOV caused an invalid page fault in
module MEGAPOV.EXE at 015f:00422585.
Registers:
EAX=00000000 CS=015f EIP=00422585 EFLGS=00010246
EBX=00917f38 SS=0167 ESP=0306f568 EBP=0306f618
ECX=00000000 DS=0167 ESI=00000001 FS=4027
EDX=00000000 ES=0167 EDI=00003856 GS=0000
Bytes at CS:EIP:
66 8b 14 48 33 c9 66 8b 0c 70 89 54 24 0c dd 5c 
Stack dump:
00000000 0306f728 0306f740 00003856 004d0672 00000001
00519b98 0306f594 00000002 0000002b 00000001 00352e30
0306f5b8 0000001f 0306f820 0306f647



  All of the following are syntax bugs found in the example scenes.
I suspect there is a naming collision with a reserved function name
i.e. image_height and image_width. Changing to image_h and image_w
allows the scenes to render as expected.

//	Persistence of Vision Ray Tracer Scene Description File
//	File: double_illuminate.pov
//	Date: 15/11/99
//	Demo double_illuminate
	
This does not work

camera {
	location < 0.0, 5, -2.5 >
#declare image_height = 240;
#declare image_width =  320;
	up image_height*y
	right image_width*x
	angle 35
	look_at < 0.0, 0.0, 0.0 >
}

This does work

camera {
	location < 0.0, 5, -2.5 >
#declare image_h = 240;
#declare image_w =  320;
	up image_h*y
	right image_w*x
	angle 35
	look_at < 0.0, 0.0, 0.0 >
}

//	Persistence of Vision Ray Tracer Scene Description File
//	File: obj_controls.pov
//	Date: 14/11/99
//	Showing no_image, no_reflection, no_shadow and projected through

Same as above problem - Change image_height and image_width renders ok.	

camera {
	location <0.0, 3, -20>
#declare image_height=240;
#declare image_width=320;
      up image_height*y
   right image_width*x
	look_at <0.0, 0.0, 0.0>
	angle 25
}

//	Persistence of Vision Ray Tracer Scene Description File
//	File: warp_maps.pov
//	Date: 15/11/99
//	Demo showing the use warps in pigment
	
Same as above two plus the declaration has 2 duplicates that are not necessary.

camera {
	location <0.0, 1.5, -11>
#declare image_width=320;
#declare image_height=240;
#declare image_width=320;
#declare image_height=240;
	up y*image_height	right x*image_width
	angle 45
	look_at <0.0, 0.0, 0.0>
}

// persistence of Vision Ray Tracer Scene Description File
// Needs Isoblob patch.
//	File: isoblob_mace.pov
//	Date: 14/11/99
//	Isoblob example scene

Same as above

camera {
	perspective 
	location <0.0, 0.0, -8>
#declare image_height=240;
#declare image_width=320;
	up y*image_height right x*image_width
	angle 55
	look_at <0.0, 0.0, 0.0>
}

//	Persistence of Vision Ray Tracer Scene Description File
//	Isosurface function demo
	
Same as above

camera {
	perspective 
	location < 0.0, 0.25, -2 >
#declare image_width=320;
#declare image_height=240;
	up y*image_height right x*image_width
	angle 45
	look_at < 0.0, 0.0, 0.0 >
	rotate y*3.5
}

-- 
Ken Tyler -  1200+ 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

>Well, yeah, that's one of my goals.  Also, Nathan seems to be better able
>to actually create a shipping product from a bunch of cool patches, whereas
>I just sit around and tell y'all how cool the next one's gonna be without
>ever taking the time to write the documentation and put it online.


I think you've done a brilliant job anyway :)
I'm quite certain that I'm not the only one with this opinion.

Juha Leppälä

Post a reply to this message

Ken <tyl### [at] pacbellnet> wrote:

> 
>   All of the following are syntax bugs found in the example scenes.
> I suspect there is a naming collision with a reserved function name
> i.e. image_height and image_width. Changing to image_h and image_w
> allows the scenes to render as expected.
> 
> //    Persistence of Vision Ray Tracer Scene Description File
> //    File: double_illuminate.pov
> //    Date: 15/11/99
> //    Demo double_illuminate
>   
> This does not work
> 
> camera {
>   location < 0.0, 5, -2.5 >
> #declare image_height = 240;
> #declare image_width =  320;
>   up image_height*y
>   right image_width*x
>   angle 35
>   look_at < 0.0, 0.0, 0.0 >
> }
> 
> This does work
> 
> camera {
>   location < 0.0, 5, -2.5 >
> #declare image_h = 240;
> #declare image_w =  320;
>   up image_h*y
>   right image_w*x
>   angle 35
>   look_at < 0.0, 0.0, 0.0 >
> }
> 

Yes, image_height and image_width are reserved keywords now.
They 'read' the image size entered in the options.

If you want to set (write) your own image_size, use the  keyword
ini_option "..."
or #declare Image_height and Image_width, using a capital letter in the
identifier.
I would like to emphasize the importance of using at least one Capital
letter in identifiers. Reserved keywords will always use only small
letters, therefore there will be no conflict with identifiers having a
capital letter. Not now and not in the future when new keywords will be
added!
The same goes for declared variables in macros. Please make it a habit
for future identifiers.

Smellenbergh


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

http://users.skynet.be/smellenbergh

Post a reply to this message

Ken wrote:

>
>
>Nathan Kopp wrote:
>
>> With all of these changes, there are likely to be bugs
>
> Ken's Bug Log for MegaPov. I'll submit more as I find them but it is
>likely to be much later today before I can work with the program more.
>
>
>The following is a program crash related problem ---
>
>//     Persistence of Vision Ray Tracer Scene Description File
>//     File: trace_hf_pattern.pov
>//     Date: 15/11/99
>//     Demo showing the use of pattern and trace function.
>
>This crash was repeatable and occured immediately after parsing and when
>the display window appeared.

Same here, it also crashes in the superpatch.
I added a #debug after i=i+i and j=j+1, and it renderd ok, but only once and 
never since.

Ingo

-- 
Photography: http://members.home.nl/ingoogni/
Pov-Ray    : http://members.home.nl/seed7/

Post a reply to this message

Ken <tyl### [at] pacbellnet> wrote...
>
> This does not work
>
> camera {
> location < 0.0, 5, -2.5 >
> #declare image_height = 240;
> #declare image_width =  320;
> up image_height*y
> right image_width*x
> angle 35
> look_at < 0.0, 0.0, 0.0 >
> }

Oops!!!

That's from when I first tried to test some SuperPatch demos... I had not
yet incorporated the image_height and image_width patches, so I had to
#declare the variables to get the scenes to parse correctly.  If you just
delete the two #declare statements (or four for that one scene), things will
work fine.

-Nathan

Post a reply to this message

Ken <tyl### [at] pacbellnet> wrote...
>
> The following is a program crash related problem ---
>
> // Persistence of Vision Ray Tracer Scene Description File
> // File: trace_hf_pattern.pov
> // Date: 15/11/99
> // Demo showing the use of pattern and trace function.
>
> This crash was repeatable and occured immediately after parsing and when
> the display window appeared.

This is apparantly a problem with the 'pattern' image type (using a pattern
to generate the height-field).  Unfortunately, I don't know exactly what
causes the problems (a bounds issue, I think).  Anyway, I've made the
height-field code a bit more fault-tolerant so that this will no longer
cause a crash.

-Nathan

Post a reply to this message

Nieminen Juha <war### [at] punarastascstutfi> wrote...
>   However I noticed that something weird happens with normals (as someone
> else has already noticed). For example the following scene renders quite
> weird and completely different from my original patch or the (fixed) uvpov
6.2.
> The correct image can be seen in p.b.images (in a thread called
"interesting
> texture using the fractal patch" or something similar):

The fix in UVPov 6.2 was like just a band-aid.  Now I think I've fixed it at
the source of the problem.  See my recent post in povray.bugreports for more
info (I think it was a reply to somebody else's bug report).

-Nathan

Post a reply to this message

Nathan Kopp wrote:

> Oops!!!
> 
> That's from when I first tried to test some SuperPatch demos... I had not
> yet incorporated the image_height and image_width patches, so I had to
> #declare the variables to get the scenes to parse correctly.  If you just
> delete the two #declare statements (or four for that one scene), things will
> work fine.
> 
> -Nathan

I really brought it up in case you wished to fix your demo scenes.
I figured out how to work around the problem on the first scene I
encountered with that camera statement :)

-- 
Ken Tyler -  1200+ 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

> Nathan Kopp wrote:
> 
> > With all of these changes, there are likely to be bugs
 
 I'll submit more as I find them...


// Persistence Of Vision raytracer version 3.1e (isosurface patch)
// sample file by R.Suzuki   <rsu### [at] etlgojp>  Apr.'99
// Torus2.pov from the iso_demo directory

#include "isocom.inc"

#declare R0=5;
#declare R1=0.7;
#declare FUNC1=function {"torus",<R0,R1>}

#declare TH= function {"TH"} //function{"FUNC1"}

isosurface {
     function {FUNC1(x,y+cos(TH*7)*0.3,z)}
     bounded_by{ box {<-R0-R1,-R0,-R0-R1>,<R0+R1,R0,R0+R1>}} 
     eval
     accuracy 0.001 
     scale <1,1,1>
     texture {ComYw}
}


The above returns the following warning:

#declare TH= function{"TH"}

isosurface {
     function {FUNC1(x,y+cos(TH* <----ERROR

F:\Program Files\POV-Ray for Windows v3.1\megapov\demos\Multipatch NPov\
Isosurface_isoblob\Iso demo\torus2.pov:15: error: 

The function 'TH' needs arguments. Should be TH(...)

Returned from renderer (non-zero return value)


If I replace #declare TH = function{"FUNC1"} the program crashes with the
following page fault

MEGAPOV caused an invalid page fault in
module MEGAPOV.EXE at 015f:0048a304.
Registers:
EAX=00000006 CS=015f EIP=0048a304 EFLGS=00010202
EBX=00000003 SS=0167 ESP=0306ee28 EBP=00916b48
ECX=00000000 DS=0167 ESI=00000000 FS=1bcf
EDX=0a524f52 ES=0167 EDI=00916b18 GS=0000
Bytes at CS:EIP:
8b 14 81 52 e8 a3 98 00 00 8b 0d 10 b0 51 00 83 
Stack dump:
00000000 00493cb5 0043e92d 004dda24 004dc598 000006e1
00916b48 0041ab75 00000000 004dc598 000006e1 00000000
0041abe3 00916b48 00916b48 0046db54
 

-- 
Ken Tyler -  1200+ 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

First, I'm not familear with isosurface stuff (I haven't done any work on it
myself... well, except for preliminary work on UV mapping which has since
been scrapped).

Using the following for the isosurface function fixes the 'not enough
argumens' problem:
     function {FUNC1(x,y+cos(TH(x,y,z)*7)*0.3,z)}

Somebody apparantly changed the implementation of isosurfaces while we
weren't looking and those default parameters aren't there anymore.  maybe
that's the problem?

About that crash... I got it to crash once... but that happened before I
replaced the #declare TH=...

But can't get it to crash again now that I'm running the debugger.
Strange...

-Nathan

Ken <tyl### [at] pacbellnet> wrote...
> The above returns the following warning:
>
> #declare TH= function{"TH"}
>
> isosurface {
>      function {FUNC1(x,y+cos(TH* <----ERROR
>
> F:\Program Files\POV-Ray for Windows v3.1\megapov\demos\Multipatch NPov\
> Isosurface_isoblob\Iso demo\torus2.pov:15: error:
>
> The function 'TH' needs arguments. Should be TH(...)
>
> Returned from renderer (non-zero return value)

Post a reply to this message

Nathan Kopp wrote:
> 
> First, I'm not familear with isosurface stuff (I haven't done any work on it
> myself...

I haven't either. Right now I am simply rendering thumbnails of all of
the demos to help you track down bugs and to get a feel for what the
patch has to offer. I have been avoiding this for too long and it's
time I start to get up to speed on some of these new features.


> About that crash... I got it to crash once... but that happened before I
> replaced the #declare TH=...
> 
> But can't get it to crash again now that I'm running the debugger.
> Strange...

With a little patience I was able to get it to stop crashing long enough
to return the following error message:

#declare TH= 
function{"FUNC1"}

isosurface {
     function {FUNC1(x,y+cos(TH <----ERROR

torus2.pov:16: error: cannot load function.

Returned from renderer (non-zero return value)

 Obviously it is a user created problem but the program seems a little
too sensitive to it.

-- 
Ken Tyler -  1200+ 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

Ken <tyl### [at] pacbellnet> wrote...
>
> I haven't either. Right now I am simply rendering thumbnails of all of
> the demos to help you track down bugs and to get a feel for what the
> patch has to offer. I have been avoiding this for too long and it's
> time I start to get up to speed on some of these new features.

If you haven't noticed, the demos for my features are usually somewhat
lacking.  If anyone wants to make up some demos for me to include, I'd be
happy.  :-)

>  Obviously it is a user created problem but the program seems a little
> too sensitive to it.

I've had it crash under two situations:
1) an error causes parsing to stop
2) the scene finishes rendering and I see a bunch of 'tried to free NULL
pointer' errors and then it crashes

-Nathan

Post a reply to this message

Your'e not, 'cause I think so too.

"Juha Leppälä" wrote:

> >Well, yeah, that's one of my goals.  Also, Nathan seems to be better able
> >to actually create a shipping product from a bunch of cool patches, whereas
> >I just sit around and tell y'all how cool the next one's gonna be without
> >ever taking the time to write the documentation and put it online.
>
> I think you've done a brilliant job anyway :)
> I'm quite certain that I'm not the only one with this opinion.
>
> Juha Leppälä

--
Samuel Benge

E-Mail: STB### [at] aolcom

Visit the still unfinished isosurface tutorial: http://members.aol.com/stbenge

Post a reply to this message

On Sat, 11 Dec 1999 00:44:03 -0500, "Nathan Kopp" <Nat### [at] Koppcom>
wrote:

>Somebody apparantly changed the implementation of isosurfaces while we
>weren't looking and those default parameters aren't there anymore.  maybe
>that's the problem?

Why's everyone looking at me? :)

Post a reply to this message

Ron Parker <par### [at] fwicom> wrote ...
> On Sat, 11 Dec 1999 00:44:03 -0500, "Nathan Kopp" <Nat### [at] Koppcom>
> wrote:
>
> >Somebody apparantly changed the implementation of isosurfaces while we
> >weren't looking and those default parameters aren't there anymore.  maybe
> >that's the problem?
>
> Why's everyone looking at me? :)
>

Don't worry.  It wasn't you.

-Nathan

Post a reply to this message

An old Chief Engineer of mine once defined an engineer as someone who sat on
the bed and kept telling his girl friend how great it was going to be ...

--
Jim

Check out my web site  http://www.kressworks.com/
It'll blow your mind (politically), stimulate your senses (artistically)
and provide scientific insights that boggle the mind!

Ron Parker <ron### [at] povrayorg> wrote in message
news:38510831@news.povray.org...
> On Fri, 10 Dec 1999 05:51:03 -0800, Ken wrote:
> >
> >Ron Parker wrote:
> >
> >> I'm chasing Mick's bug at the moment, and I will continue to do so
until
> >> I catch it, but I am considering doing so, yes.
> >
> > Well I personaly have no problem with this as long as it means it frees
> >up more of your time to work on the official release of POV-Ray v 3.5.
>
> Well, yeah, that's one of my goals.  Also, Nathan seems to be better able
> to actually create a shipping product from a bunch of cool patches,
whereas
> I just sit around and tell y'all how cool the next one's gonna be without
> ever taking the time to write the documentation and put it online.
>
> --
> These are my opinions.  I do NOT speak for the POV-Team.
> The superpatch: http://www2.fwi.com/~parkerr/superpatch/
> My other stuff: http://www2.fwi.com/~parkerr/traces.html

Post a reply to this message