|
 |
Bugreport taken from:
http://www.povray.org/download/3.5-bugs.php
in particularly
http://news.povray.org/3c4bb31d$1@news.povray.org
This bugreport is not marked as a job, I thought it was because
already fixed for the next release, but I see now it's in the
bottom half of the list. So here's a note:
The problem is that an expression like:
#declare vvv = <1, 0, 0> +1*t;
results in a 4D vector vvv = <1,0,0,0>
this is because 1 is firstly promoted to a 3D vector (<1,1,1>)
as a right hand side of the binary +, and then it is promoted
to a 4D vector (<1,1,1,0>) as a left hand side of the * operator.
Multiplying it by t (<0,0,0,1>) results in a 4D <0,0,0,0> that
added to <1,0,0> only promotes it to <1,0,0,0>.
Here's a patch that shows a possible solution, but I'm not
certain it's fully correct. (The patch is against express.cpp
of the linux sources version 3.50a)
HTH Massimo
--- src/express.cpp.ex 2002-12-20 19:27:58.000000000 +0000
+++ src/express.cpp 2002-12-20 19:28:15.000000000 +0000
@@ -1582,7 +1582,7 @@
Parse_Num_Term(Express,Terms);
- Local_Terms=*Terms;
+ Local_Terms=1;
EXPECT
CASE (PLUS_TOKEN)
Post a reply to this message
|
|
|
|
In article <3e0368ee$1@news.povray.org> , "Massimo Valentini"
<six### [at] inwind it> wrote:
> Bugreport taken from:
>
> http://www.povray.org/download/3.5-bugs.php
>
> in particularly
>
> http://news.povray.org/3c4bb31d$1@news.povray.org
>
> This bugreport is not marked as a job, I thought it was because
> already fixed for the next release, but I see now it's in the
> bottom half of the list.
No, it doesn't have a job number iirc. Here is the current state of most
bugs listed on that page:
job000038
Poly Object Bug
Ron Parker says:
This one is unlikely to be fixed soon, unless somebody sees something I
didn't. It looks like a root-finding inaccuracy of some kind.
Suspended by Thorsten
-----
from povray.bugreports
date Wed, 10 Nov 1999 05:50:04 -0800
posted by Ken <tyl### [at] pacbellnet>
message <382a3063@news.povray.org>
This bug concerns the poly object using POV-Ray Windows v3.1g.watcom
on a Pentium 200 Win98 platform. The error manifests itself as a black
pixelated line on the objects surface on the same plane and level as the
camera sits. The strum keyword does not appear to have any influence on
the problem.
It should be noted however that the same object does render correctly
using POV-Ray v2.2 for DOS and in POV-Ray for Windows v3.01.watcom.win32
either with or without the sturm keyword. This suggests a strong
possibility
that it is indeed a version related bug.
This same problem can be seen with the Twin_Glob 6th order poly object
from the shapesq.inc file that is included with the distribution of
POV-Ray.
This bug has been verified by Ron Parker.
// Example of problem
camera { location <0,0,-10> look_at 0 angle 25 }
light_source { <0,1,-100> color rgb 1 }
#declare Heart =
poly { 6,<
8.0,0,0,0,12,0,0,12,0,-12,0,0,0,0,0,0,0,0,0,0,6,0,0,12,0,-12,0,0,0,0,6,
-0.1,-12,0,6,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1,0,0,3,0,-3,0,0,
0.0,0,3,-1,-6,0,3,0,0,0,0,0,0,1,0,-3,0,3,0,-1>
}
// sturm }
object { Heart rotate <-90,90,0> pigment { red 1 } }
RLP, 10 Jan 2001: The bug does indeed exist, but it is not in the camera
plane. It is in
the y=0 plane, as can be seen by moving the camera upward while focusing
on the same point.
Whatever it is, it sure isn't obvious.
job000093 on 2001/03/11 by thorsten *suspended*
Implement 16 bit image map reading for PNG and/or Targa image files.
job000137 on 2002/03/29 by thorsten *suspended*
Highlight bug?
See article <3b2fdb5b@news.povray.org> by "Rune"
<run### [at] mobilixnetdk>
Highlights, when used together with normals, are visible in places where
they should be in shadow. The same problem once existed for reflection, but
it was fixed so reflected rays couldn't go inside the object. The same fix
need to be applied to highlights as well.
In the code below if you change Sign to be 1, the light_source is behind
the
plane, and yet highlights are still visible. Note that because the
reflection is fixed, there are no incorrect reflections of the sphere even
though it is located at the same location as the light_source.
#declare Sign = -1;
light_source {Sign*100*z, color red 1}
sphere {Sign*100*z, 20 pigment {color green 10} no_shadow}
camera {location -5*z}
background {color rgb 0.1}
plane {
-z, 0
pigment {color <0,0,0>}
normal {bumps 3}
finish {phong 2 reflection 1}
}
The bug exists in POV-Ray 3.1, MegaPov 0.7 and POV-Ray 3.5 pre-beta 10.
Also reported in http://news.povray.org/povray.beta-test/18760/
job000177
(feature request) radiosity sampling, with fix method
Report:
http://news.povray.org/povray.beta-test/19143/
Note: According to Nathan the effect is "at least somewhat desired". There
might
also be problems with the proposed solution, so I marked it as feature
request
and suspended the job because radiosity is experimental.
job000207
radiosity doesn't take Double-illuminate into account
Reported:
http://news.povray.org/povray.beta-test/20319/ and
http://news.povray.org/povray.beta-test/20102/
job000226
"Camera inside non-hollow object" reported in some light_groups
Reported:
http://news.povray.org/povray.beta-test/20803/137765/
job000230
Using media and fog has strange effects (incorrect colors)
Reported in:
media & fog bug?
http://news.povray.org/3c1379e0$1@news.povray.org
Another Media+fog problem report with unclear bug status:
Funky fog vs. media
http://news.povray.org/3c642f94$1@news.povray.org
____________________________________________________
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
|
|
