POV-Ray : Newsgroups : povray.unofficial.patches : height-field Krach Server Time
2 Sep 2024 12:12:54 EDT (-0400)
  height-field Krach (Message 1 to 7 of 7)  
From: Rodolphe
Subject: height-field Krach
Date: 5 Feb 2000 03:01:20
Message: <389bd8d0@news.povray.org>
a small simpler example studied.
un petit exemple plus simple a etudier
best regard
Rodolphe
galerie: http://perso.infonie.fr/rod.gelaude
          annuaire "Povray Sites"
     http://www.multimania.com/povsite

news://news.newz.net/nzn.fr.3d.pov


Post a reply to this message


Attachments:
Download 'bug.pov.txt' (2 KB)

From: Nieminen Juha
Subject: Re: height-field Krach
Date: 6 Feb 2000 07:07:46
Message: <389d6412@news.povray.org>
Please don't send binary attachments to non-binaries groups.
  I know that some programs don't show the difference between a text and
a binary-attached text (user friendly?) and one can send one by mistake.
  Someone who knows better than me can tell you the exact procedure to avoid
text attachments in binary format.

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

From: Bob Hughes
Subject: Re: height-field Krach
Date: 6 Feb 2000 09:27:30
Message: <389d84d2@news.povray.org>
It seems to be related only to the height scaling near as I can tell, as
though it begins to break down the triangle mesh thing of the HF.  Possible that
it could be any large scaling that would do this too but I only saw it doing it
with large y scales, large x or z scales didn't cause any problems.
  Another thing I found by trying this scene file out is that when I
Ctrl-Alt-Del out of MegaPov (it essentially becomes unstoppable within the
program) there are leftover MegaPovs left running even though it has been End
Task'd.
It had gotten slower to load on each subsequent run and then I realized there
were multiple instances of MegaPov left behind.  A real major crash then I
guess, or at least mysterious.

Bob

"Nieminen Juha" <war### [at] punarastascstutfi> wrote in message
news:389d6412@news.povray.org...
|   Please don't send binary attachments to non-binaries groups.
|   I know that some programs don't show the difference between a text and
| a binary-attached text (user friendly?) and one can send one by mistake.
|   Someone who knows better than me can tell you the exact procedure to avoid
| text attachments in binary format.
|
| --
| 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

From: Bob Hughes
Subject: Re: height-field Krach
Date: 6 Feb 2000 09:48:44
Message: <389d89cc@news.povray.org>
It just occurred to me, what if the HF is actually getting a kind of degenerate
triangle happening when the parts close in so much.  I picture it like this:  a
peak (or trough) is basically a polygon of triangles which would come very
closely folded together like if you were to stretch a pyramid very far upward
until near the point the surfaces are almost touching.  The problem with that
theory is why would the whole triangle collapse into another if the base is
still at an acceptable width.  Changing only the height shouldn't change the
bases, unless they were somehow moved inward upon themselves.
Anyone else follow that line of reasoning?  Just my idea on it, I don't know the
true structure of a HF.

Bob

"Bob Hughes" <omn### [at] hotmailcom?subject=PoV-News:> wrote in message
news:389d84d2@news.povray.org...
|   It seems to be related only to the height scaling near as I can tell, as
| though it begins to break down the triangle mesh thing of the HF.  Possible
that
| it could be any large scaling that would do this too but I only saw it doing
it
| with large y scales, large x or z scales didn't cause any problems.
|   Another thing I found by trying this scene file out is that when I
| Ctrl-Alt-Del out of MegaPov (it essentially becomes unstoppable within the
| program) there are leftover MegaPovs left running even though it has been End
| Task'd.
| It had gotten slower to load on each subsequent run and then I realized there
| were multiple instances of MegaPov left behind.  A real major crash then I
| guess, or at least mysterious.
|
| Bob
|
| "Nieminen Juha" <war### [at] punarastascstutfi> wrote in message
| news:389d6412@news.povray.org...
| |   Please don't send binary attachments to non-binaries groups.
| |   I know that some programs don't show the difference between a text and
| | a binary-attached text (user friendly?) and one can send one by mistake.
| |   Someone who knows better than me can tell you the exact procedure to avoid
| | text attachments in binary format.
| |
| | --
| | 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

From: Nathan Kopp
Subject: Re: height-field Krach
Date: 6 Feb 2000 18:06:14
Message: <389dfe66@news.povray.org>
Rodolphe <rod### [at] infoniefr> wrote...
> a small simpler example studied.
> un petit exemple plus simple a etudier
> best regard

I've found (and fixed) the problem.  The problem is a percision problem.
During shadow testing on the height_field, POV shoots a ray from the
height_field to the light.  If POV is using the light buffer, it my try
another ray to see if it finds a closer intersection.  The problem is that
it hits the same spot again and again and again.  Each time, the
intersection depth is incorrect and reports 1e-7 as the depth instead of
zero.

I would think that this would affect the official version as well, but there
are two differences between MegaPov and the official version that could
cause this: 1) MegaPov is compiled with VC++ and 3.1g used Watcom; 2)
MegaPov has a smaller EPSILON in config.h (I have not tried changing EPSILON
so I don't know if this was the origin of the problem).

The solution was to utilize a Small_Tolerance value to determine if a
precision error is occuring.  Small_Tolerance and SHADOW_TOLERANCE (two
#defines) are used in a variety of places in POV for this vary reason.  For
some reason, though, they were not used in the function Intersect_Light_Tree
in lbuffer.c.

-Nathan


Post a reply to this message

From: Rodolphe
Subject: Re: height-field Krach
Date: 7 Feb 2000 13:43:39
Message: <389f125b@news.povray.org>
thank Nathan :)


Post a reply to this message

From: Rodolphe
Subject: Re: height-field Krach
Date: 7 Feb 2000 13:44:18
Message: <389f1282@news.povray.org>
oups, sorry Juha

>  Please don't send binary attachments to non-binaries groups.
>  I know that some programs don't show the difference between a text and
>a binary-attached text (user friendly?) and one can send one by mistake.
>  Someone who knows better than me can tell you the exact procedure to
avoid
>text attachments in binary format.
>
>--
>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

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