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.



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


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