![](/i/fill.gif) |
![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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)
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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] punarastas cs tut fi> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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] hotmail com?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] punarastas cs tut fi> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Rodolphe <rod### [at] infonie fr> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
thank Nathan :)
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |