 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Here are the known and confirmed bugs as per today. Corrections to the list
are still very welcome.
Blob problem
http://news.povray.org/3b99052c@news.povray.org
Blob : Toward a solution
http://news.povray.org/3B991C90.D715B7A3@free.fr
Superellipsoid epsilon to big ?
http://news.povray.org/3b992a81@news.povray.org
Additional (?) blob bug
http://news.povray.org/Xns9115B92CF7D8ACQ@204.213.191.226
hf_gray_16 + png creates wrong output image
http://news.povray.org/3BA3BAE6.4671C0BB@free.fr
Blob rendering error
http://news.povray.org/Xns91203DC7F3CCQ@204.213.191.226
Small window title bug
(Title switches back to "POV-Ray for Windows" after minimize or restore. )
http://news.povray.org/3ba92966$1@news.povray.org
16-bit PGM pigment and height field problems
http://news.povray.org/3ba99adb@news.povray.org
Blend map crash
http://news.povray.org/3ba9f8e9$1@news.povray.org
Radiosity with recursion > 1
(With recursion_limit > 1 clear axis aligned bands appear on the surfaces.)
http://news.povray.org/3BAB71AF.B0F503CA@reading.ac.uk
Rendering animation (MS Windows)
(Message that indicates the frame to be render is displayed AFTER the
rendering.)
http://news.povray.org/3BAC1D0C.74A4A503@free.fr
Stop during mosaic: crash
http://news.povray.org/Xns9126925CDC108seed7@povray.org
sin(X)^sin(X) -> crash!
http://news.povray.org/3baf7992@news.povray.org
Bug with parse_string
http://news.povray.org/9pk0rto8s07dnm320f5m503aqu43ak6g3p@4ax.com
Spline bug
(The spline path is all wrong when certain time values are used.)
http://news.povray.org/3bb41dc8@news.povray.org
Radiosity crash when user stops render during pretrace.
http://news.povray.org/3bb4605d$1@news.povray.org
Highlight bug
http://news.povray.org/3bb4cf08@news.povray.org
Macro bug
(POV can dereference a deallocated pointer if you return a local from a
macro.)
http://news.povray.org/3BB4ED11.8EC69CEC@hotmail.com
Crash after constant function
http://news.povray.org/kc3hqtkgj93f82rpkj6puvlj8f5cs7nk0q@4ax.com
Bug with intersection stack (with crash)
http://news.povray.org/5f13rtc0v0rso4fk7lut5e0980qa9g756b@4ax.com
Crash with long strings
(Ignore documentation bug report.)
3b54rt8puoibdtdsquqgv1fuo0m9mn6k30@4ax.com
Rune
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Wasn't it Rune who wrote:
>Here are the known and confirmed bugs as per today. Corrections to the list
>are still very welcome.
Whatever happened to
Isosurface *disappears* at high resolution (fwd)
http://news.povray.org/3bb0b351@news.povray.org
?
Does it perhaps need more confirmation, and if so in what way?
--
Mike Williams
Gentleman of Leisure
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <Wif### [at] econym demoncouk> , Mike Williams
<mik### [at] nospamplease> wrote:
>
> Whatever happened to
> Isosurface *disappears* at high resolution (fwd)
> http://news.povray.org/3bb0b351@news.povray.org
> ?
> Does it perhaps need more confirmation, and if so in what way?
Not a bug, but a limit in the crackle function when used with isosurfaces.
Thorsten
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Wasn't it Thorsten Froehlich who wrote:
>In article <Wif### [at] econymdemoncouk> , Mike Williams
><mik### [at] nospamplease> wrote:
>
>>
>> Whatever happened to
>> Isosurface *disappears* at high resolution (fwd)
>> http://news.povray.org/3bb0b351@news.povray.org
>> ?
>> Does it perhaps need more confirmation, and if so in what way?
>
>Not a bug, but a limit in the crackle function when used with isosurfaces.
What? It's considered perfectly OK for the crackle pattern to completely
disappear over 63% of the image because the root solver has a bit of a
problem with one pixel? I claim that it's still a bug. All the relevant
variables should be reset after the troublesome pixel, and it should
attempt to render the rest of the image rather than giving up
completely.
I also don't believe that anyone has actually produced any evidence that
the effect is related to the crackle pattern. Whatever is causing it is
quite rare and it just happen by chance that the only scene file that
provokes the disappearance contains crackle.
--
Mike Williams
Gentleman of Leisure
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Mike Williams schrieb in Nachricht ...
>I also don't believe that anyone has actually produced any evidence that
>the effect is related to the crackle pattern. Whatever is causing it is
>quite rare and it just happen by chance that the only scene file that
>provokes the disappearance contains crackle.
>
IMO it is not directly related with the crackle function, cause I had
similar effects with other functions in MegaPov. I don't know for sure, but
I think all it need's is a somewhat complicate function (pigment functions
may help a lot) and a insufficient accuracy value. I remember one Iso which
used a brick-pigment-function and showed the same effect. Increasing the
accuracy always helped.
I think, it's often necessary to set the accuracy value quite low to get
reliable results. That makes things quite slow, but I can't consider this as
a bug.
What is really strange, is that removing those three blank lines in the
example code you provided changed the output! Thorsten might not want to
hear this (:-)), but there is a definitive relation between these to thing!
So IMO, it is worth having another look at the isosurface code, if there is
any time left, but I think to consider the mentioned behaviour a real bug,
there should be more evidences that it is not just an accuracy problem. But
as I'm not a programmer, it's not at all my decision.
Marc-Hendrik
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Rune" <run### [at] mobilixnetdk> wrote in message
news:3bb8e6a2@news.povray.org...
> Here are the known and confirmed bugs as per today. Corrections to the
list
> are still very welcome.
>
Not meaning to be a pain or anything, but I've posted a bug report that no
one seems to have even looked at, or at least replied to. It seems to be
fairly serious and easily reproducible.
http://news.povray.org/3bb2bcc4@news.povray.org
also, Xref: news.povray.org povray.beta-test:1359
See also my own reply. I'd just like at least a confirmation that I'm not
crazy :-)
Thanks,
Michael
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <Zml### [at] econymdemoncouk> , Mike Williams
<mik### [at] nospamplease> wrote:
> What? It's considered perfectly OK for the crackle pattern to completely
> disappear over 63% of the image because the root solver has a bit of a
> problem with one pixel?
No, the root solves does *not* have a problem (it is the same one as in
MegaPOV BTW). The *function* is simply unsuitable for an isosurface in many
cases. An isosurface technically requires certain properties of the
function, in particular that it is well-defined (following the constraints
required by isosurfaces) within the whole isosurface object's space. If it
is not, what you have isn't really an isosurface also POV-Ray frequently
allows you to still render it (but that is just your luck).
Thorsten
____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde
Visit POV-Ray on the web: http://mac.povray.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3bb9851e@news.povray.org> , "Marc-Hendrik Bremer"
<Mar### [at] t-onlinede> wrote:
> What is really strange, is that removing those three blank lines in the
> example code you provided changed the output! Thorsten might not want to
> hear this (:-)), but there is a definitive relation between these to thing!
No, blank lines do not cause this. Computers are no magic black boxes and
these lines can under no condition *anything* to do with the problem. Lets
not spread false rumors about the inner working of computers or POV-Ray,
please. I am sure everybody in the POV-Team will say the same (but I have
not asked).
It is most likely that repeated renders (because of different random
numbers) exhibit the effect in different places or not at all.
Thorsten
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ok, you are right. It was probably just coincidence, that in my first test,
the Iso vanished in the first render, rendered properly after removing those
three lines and vanished again in the third render, when I added those three
lines again. To be honest, I can't reproduce this behaviour again.
As to the magic black boxes: I might not be familiar with the pov-code or
even the programming language it's written in, but I had my slice of
assembler programming back in those 6502-days. I really know that there is
no magic in those boxes - but I also know that mistakes are possible. All we
beta-testers can do, is to describe the behaviour of the program you
programmers give us to play/work with. We/I might not look intensiv enough
in a problem when we report it, but we/I clearly don't want to lead you to
false tracks or distract you or somethink like that.
Best regards,
Marc-Hendrik
Thorsten Froehlich schrieb in Nachricht <3bb9ebb2@news.povray.org>...
>In article <3bb9851e@news.povray.org> , "Marc-Hendrik Bremer"
><Mar### [at] t-onlinede> wrote:
>
>> What is really strange, is that removing those three blank lines in the
>> example code you provided changed the output! Thorsten might not want to
>> hear this (:-)), but there is a definitive relation between these to
thing!
>
>No, blank lines do not cause this. Computers are no magic black boxes and
>these lines can under no condition *anything* to do with the problem. Lets
>not spread false rumors about the inner working of computers or POV-Ray,
>please. I am sure everybody in the POV-Team will say the same (but I have
>not asked).
>
>It is most likely that repeated renders (because of different random
>numbers) exhibit the effect in different places or not at all.
>
>
> Thorsten
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
What about the "sphere_sweep and radiosity" bug? I hope I don't look like a
monomaniac, but IIRC C. Hormann could replicate that as well... needs this
more confirmation?
--
Jonathan
"Rune" <run### [at] mobilixnetdk> ha scritto nel messaggio
news:3bb8e6a2@news.povray.org...
> Here are the known and confirmed bugs as per today. Corrections to the
list
> are still very welcome.
>
> Blob problem
> http://news.povray.org/3b99052c@news.povray.org
>
> Blob : Toward a solution
> http://news.povray.org/3B991C90.D715B7A3@free.fr
>
> Superellipsoid epsilon to big ?
> http://news.povray.org/3b992a81@news.povray.org
>
> Additional (?) blob bug
> http://news.povray.org/Xns9115B92CF7D8ACQ@204.213.191.226
>
> hf_gray_16 + png creates wrong output image
> http://news.povray.org/3BA3BAE6.4671C0BB@free.fr
>
> Blob rendering error
> http://news.povray.org/Xns91203DC7F3CCQ@204.213.191.226
>
> Small window title bug
> (Title switches back to "POV-Ray for Windows" after minimize or restore. )
> http://news.povray.org/3ba92966$1@news.povray.org
>
> 16-bit PGM pigment and height field problems
> http://news.povray.org/3ba99adb@news.povray.org
>
> Blend map crash
> http://news.povray.org/3ba9f8e9$1@news.povray.org
>
> Radiosity with recursion > 1
> (With recursion_limit > 1 clear axis aligned bands appear on the
surfaces.)
> http://news.povray.org/3BAB71AF.B0F503CA@reading.ac.uk
>
> Rendering animation (MS Windows)
> (Message that indicates the frame to be render is displayed AFTER the
> rendering.)
> http://news.povray.org/3BAC1D0C.74A4A503@free.fr
>
> Stop during mosaic: crash
> http://news.povray.org/Xns9126925CDC108seed7@povray.org
>
> sin(X)^sin(X) -> crash!
> http://news.povray.org/3baf7992@news.povray.org
>
> Bug with parse_string
> http://news.povray.org/9pk0rto8s07dnm320f5m503aqu43ak6g3p@4ax.com
>
> Spline bug
> (The spline path is all wrong when certain time values are used.)
> http://news.povray.org/3bb41dc8@news.povray.org
>
> Radiosity crash when user stops render during pretrace.
> http://news.povray.org/3bb4605d$1@news.povray.org
>
> Highlight bug
> http://news.povray.org/3bb4cf08@news.povray.org
>
> Macro bug
> (POV can dereference a deallocated pointer if you return a local from a
> macro.)
> http://news.povray.org/3BB4ED11.8EC69CEC@hotmail.com
>
> Crash after constant function
> http://news.povray.org/kc3hqtkgj93f82rpkj6puvlj8f5cs7nk0q@4ax.com
>
> Bug with intersection stack (with crash)
> http://news.povray.org/5f13rtc0v0rso4fk7lut5e0980qa9g756b@4ax.com
>
> Crash with long strings
> (Ignore documentation bug report.)
> 3b54rt8puoibdtdsquqgv1fuo0m9mn6k30@4ax.com
>
> Rune
>
>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
