 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In case the POV team hates sifting through all of those RTFMs to
find the real bugs, I've consolidated the bugs that I feel are
'real' here, along with pointers to any fixes that have been
suggested by people in this group. I also have a few new (and
not yet well tested) fixes to some old bugs here.
I have tested all of these bug fixes and they have fixed the
problem. Of course, side effects have not yet been thoroughly
investigated.
-Nathan Kopp
P.S. If the POV-Team has fixed these or plans to, I aggree with
Nieminen that we'd appreciate some feedback. ;)
=========================
double sided illumination
=========================
thread: "simple incorrect shading of bicubic patch example"
bug: Bicubic patches and smooth triangles are double-illuminated
by default (and this cannot be turned off). Not really a
'bug', but it is not consistent.
fix: new "double_illuminate" keyword
see http://nathan.kopp.com/patched.htm - not well tested
=========================
image map interpolation
=========================
thread: "interpolate wraparound & once"
bug: Interpolation assumes wrap-around even when the once keyword
is used.
fix: not done yet.. shouldn't be too hard
=============================
symbol table & infinite macro
=============================
thread: "POV 3.1 Infinite Recursion Bug-Fix"
bug: When the maximum number of symbol tables is reached, POV
calls Destroy_Table with an incorrect index, causing a
crash
fix: See the thread. Nigel Stewart provides a good fix.
=========================
Prism bug
=========================
thread: "Potential render bug in POV"
bug: Ghost line appears sometimes when rendering a prism. The
cause has not been determined. Note, the example given
is not very good, but all objects except the prism can be
removed from the scene and the bug remains.
fix: unknown
========================================
Renderer lockup (affects Win95 at least)
========================================
thread: "Bug: divide by zero in scene file causes renderer to hang"
bug: The line "rotate <0,0,360/clock>" supposedly causes the renderer
to lock up. I have not tried to confirm this bug.
fix: unknown
=========================
Another prism bug
=========================
thread: "prism, linear spline, conic sweep bug"
bug: Incorrect rendering of a conic sweep prism
fix: See the thread. Darius Davis provides a fix.
=========================================
Large EPSILON value in Windows CONFIG.INI
=========================================
thread: -
bug: CONFIG.INI in DOS and Windows sets EPSILON to 10e-5, which
causes all sorts of problems when rendering very small or very
large objects.
fix: Change EPSILON to something smaller, like 10e-12
=========================
4d vector bug
=========================
thread: "Can't define 4d vectors"
bug: 4D & 5D vectors can't be defined as the documentation says
they can be.
fix: Change the documentation. Only 3d vectors can be defined.
4D and 5D COLORS can be defined, but not vectors.
=========================
2d vector bug
=========================
thread: "2-d vector components (uv) bug"
bug: When 2d vectors are defined, the number of components is not
set properly in EXPRESS.C, so the components cannot be accessed
using the dot operators (e.g. a.x works but a.y does not)
fix: This requires two changes, both in EXPRESS.C:
1) In Parse_Num_Factor(), around line 624, add the line
shown below (with surrounding lines included):
---------------
CASE (LEFT_ANGLE_TOKEN)
*Terms=2; /* NK 1998 - added this line (suggested by Thomas Willhalm)*/
Express[X] = Parse_Float(); Parse_Comma();
Express[Y] = Parse_Float(); Parse_Comma();
---------------
2) In Parse_Vector_Float(), right before the line
"Have_Vector=(Terms==3);", add:
---------------
/* NK 1998 - promote all 2-component vectors to 3-component vectors...
this fixes various 2-component vector bugs */
if (Terms==2)
Terms++;
/* NK ---- */
---------------
=========================
normal average bug
=========================
thread: "Is the average normal bug fixed yet?"
bug: Error with average normals (and other normals, too), caused
by flipping the surface normal after perturbing it.
fix: This is fixed by the changes made to "compute_lighted_texture()"
made when fixing the reflection bug.
It basically consists of moving the code that flips the
direction of the RawNormal to the very top of the function so
that it always executes. The normal-flipping code in the
normal-perturbing loop then must be removed.
=========================
Reflection bug
=========================
thread: "Reflection Bug?"
bug: You can see through reflective surfaces when perturbed normals
are used. For an explanation, see the thread.
fix: See the thread. I (Nathan) provide a fix which also fixes the
normal average bug.
=========================
#local 'bug'
=========================
thread: "#local 'bug' cripples usefulness"
bug: Actually, it's a limitation. Basically, when you have a local
variable, it must be of the same type as the non-local variable
if a variable of that name already exists. The title of the
thread says it all. I'm going to put a personal gripe here:
I really hate the error "Attempted to redefine float identifier
as vector". I should be able to redefine anything as anything
else whenever I want to (with a warning, of course).
fix: I've got an educated guess here:
Change Test_Redefine() (in PARSE.C) to look like this:
--------
void Test_Redefine(TOKEN Previous, TOKEN *NumberPtr, void *Data)
{
char *oldt, *newt;
if ((Previous == IDENTIFIER_TOKEN) || (Previous == EMPTY_ARRAY_TOKEN))
{
return;
}
Destroy_Ident_Data(Data,Previous);
}
----------
Note: This gets rid of ALL redefine errors, not just ones
associated with local variables.
Warning: This may have some problems, but I just tried
it and it seemed to work. First, I could easily re-define
a float as a vector or even a texture as a float. The I put
it to a great test: I made a macro that used a local variable
that had the same name as a normal in my scene (and declared
it to be a vector). Then I called the macro between the
normal's declaration and it's use. In the official POV, it
failed. In my compile, everything worked.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3664484F.161EE94C@Kopp.com> , Nathan Kopp <Nat### [at] Kopp com> wrote:
>In case the POV team hates sifting through all of those RTFMs to
>find the real bugs, I've consolidated the bugs that I feel are
>'real' here, along with pointers to any fixes that have been
>suggested by people in this group. I also have a few new (and
>not yet well tested) fixes to some old bugs here.
>
>I have tested all of these bug fixes and they have fixed the
>problem. Of course, side effects have not yet been thoroughly
>investigated.
>
>-Nathan Kopp
>
>P.S. If the POV-Team has fixed these or plans to, I aggree with
>Nieminen that we'd appreciate some feedback. ;)
Please see my 2nd post in "persistent bugs?".
I will forward your list as well.
Thorsten
____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: Tho### [at] csicom
e-mail: fro### [at] charliecnsiitedu
I am a member of the POV-Ray Team.
Visit POV-Ray on the web: http://www.povray.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Tue, 01 Dec 1998 14:49:36 -0500, Nathan Kopp <Nat### [at] Koppcom>
wrote:
>=========================
>Prism bug
>=========================
> thread: "Potential render bug in POV"
> bug: Ghost line appears sometimes when rendering a prism. The
> cause has not been determined. Note, the example given
> is not very good, but all objects except the prism can be
> removed from the scene and the bug remains.
> fix: unknown
This one was reported during the 3.0 beta period, in case it
matters (it doesn't.) I have a scene somewhere that duplicates
it quite noticeably. The problem appears to occur when the
insideness-testing algorithm intersects exactly at a vertex.
I haven't found the exact fix yet, despite years of trying.
>=========================================
>Large EPSILON value in Windows CONFIG.INI
>=========================================
> thread: -
> bug: CONFIG.INI in DOS and Windows sets EPSILON to 10e-5, which
> causes all sorts of problems when rendering very small or very
> large objects.
> fix: Change EPSILON to something smaller, like 10e-12
For the sphere scaling bug, at least, someone else suggested a better
fix that adapts to smaller-sized objects without the side-effects of
modifying EPSILON indiscriminately. Also, you meant config.h. :)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thanks for forwarding the list... I made the (incorrect) assumption that this
was an official place to post bug reports. In my list I often say "see the
tread for so-and-so's fix to this bug". If possible, could you forward those
fixes to the rest of the POV-Team, too? Thanks.
-Nathan
Thorsten Froehlich wrote:
>
> Please see my 2nd post in "persistent bugs?".
>
> I will forward your list as well.
>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ronald L. Parker wrote:
>
> For the sphere scaling bug, at least, someone else suggested a better
> fix that adapts to smaller-sized objects without the side-effects of
> modifying EPSILON indiscriminately. Also, you meant config.h. :)
I agree. I did mean config.h. And the Dan Connelly's proposed change for
the sphere scaling bug is a good one. However, I still think that the
EPSILON in the DOS/Win versions needs to be changed. It is much bigger
than the EPSILON used for Unix/Mac machines (or so I'm told). Why? They
should be consistent, IMHO. 10e-5 is really quite large... for an epsilon.
It is only 0.00001.
-Nathan Kopp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3664BB68.C813438D@Kopp.com> , Nathan Kopp <Nat### [at] Koppcom> wrote:
>If possible, could you forward those
>fixes to the rest of the POV-Team, too?
Yes, by posting them in the (private) POVRAY forum section they are available for
everyone in the team.
Thorsten
Post a reply to this message
|
|
| |
| |
|
|
From: Darius Davis
Subject: Re: List of bugs - image map fix + more on prisms
Date: 7 Dec 1998 05:18:03
Message: <366CA6B8.5BD3@acm.org>
|
|
|
| |
| |
|
|
> =========================
> Prism bug
> =========================
> thread: "Potential render bug in POV"
> bug: Ghost line appears sometimes when rendering a prism. The
> cause has not been determined. Note, the example given
> is not very good, but all objects except the prism can be
> removed from the scene and the bug remains.
> fix: unknown
Just for the record, a fix for this bug is included in my fix for the
other prism bugs (below)
> =========================
> Another prism bug
> =========================
> thread: "prism, linear spline, conic sweep bug"
> bug: Incorrect rendering of a conic sweep prism
> fix: See the thread. Darius Davis provides a fix.
I've just completed a 'proper' fix for this, which I've posted in the
thread and sent to the POV bug-reporting email address. There are
actually several problems with conic_sweep prisms - with end-caps,
normals and 'insideness' testing.
Cheers,
Darius
Post a reply to this message
|
|
| |
| |
|
|
From: Darius Davis
Subject: Re: List of bugs - image map fix
Date: 7 Dec 1998 05:37:44
Message: <366CAB56.28C9@acm.org>
|
|
|
| |
| |
|
|
Hi all,
OK, enough silly games, this time I'll remember to paste the text for
the fix into the news message :)
> =========================
> image map interpolation
> =========================
> thread: "interpolate wraparound & once"
> bug: Interpolation assumes wrap-around even when the once keyword
> is used.
> fix: not done yet.. shouldn't be too hard
Well, it's done now. This code will stretch the image a bit if both
'interpolate 'and 'once' are specified. This makes the edges line up
neatly. I've given it a bit of testing, but more would always be
appreciated. The code is for 3.02, which has a different style of
function declaration to 3.1, but that isn't difficult to fix :) I
haven't sent this to the POV-Team yet, I'll wait for any feedback first.
Cheers,
Darius
---------------------------------------------------------------
To fix, add a new function in IMAGE.C:
int once_map(once_flag, interpolate_flag, image_dimension, x, result)
int once_flag, interpolate_flag;
DBL image_dimension, x;
DBL *result;
{
if (once_flag)
{
/*
* With 'once' specified, a mapping is only present within 0..1,
and
* the edges of the image are not used for interpolation!
*/
if ((x < 0.0) || (x >= 1.0))
{
return 0;
}
if (interpolate_flag)
{
*result = (x * (image_dimension - 1.0));
}
else
{
*result = (x * image_dimension);
}
return 1;
}
/*
* 'once' is not specified, use entire image
*/
*result = fmod(x * image_dimension, image_dimension);
return 1;
}
Replace the following lines of cylindrical_image_map:
if ((Image->Once_Flag) && ((y < 0.0) || (y > 1.0)))
{
return 0;
}
*v = fmod(y * Image->height, Image->height);
with these:
if (once_map(Image->Once_Flag, (Image->Interpolation_Type !=
NO_INTERPOLATION), Image->height, y, v) == 0)
{
return 0;
}
and replace function planar_image_map with the following:
static int planar_image_map(EPoint, Image, u, v)
VECTOR EPoint;
IMAGE *Image;
DBL *u, *v;
{
int i;
for (i = X; i <= Z; i++)
{
if (Image->Gradient[i] > 0.0)
{
if (once_map(Image->Once_Flag, (Image->Interpolation_Type !=
NO_INTERPOLATION), Image->width, EPoint[i], u) == 0)
{
return 0;
}
}
else
if (Image->Gradient[i] < 0.0)
{
if (once_map(Image->Once_Flag, (Image->Interpolation_Type !=
NO_INTERPOLATION), Image->height, EPoint[i], v) == 0)
{
return 0;
}
}
}
return 1;
}
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <366### [at] acmorg> , Darius Davis <Dar### [at] acmorg> wrote:
>The code is for 3.02, which has a different style of
> function declaration to 3.1
Yes, it has. Old style function headers are not part of the ISO C++ definition so
this changed.
Thorsten
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
