POV-Ray : Newsgroups : povray.programming : I found a bug in povray source code 3.6... Take a look... Server Time
22 Dec 2024 12:55:37 EST (-0500)
  I found a bug in povray source code 3.6... Take a look... (Message 1 to 2 of 2)  
From: AGPX
Subject: I found a bug in povray source code 3.6... Take a look...
Date: 19 Sep 2004 18:45:01
Message: <web.414e0af6e2bfad144e1dae950@news.povray.org>
Hello,

I think to have found some bugs in povray's source code version 3.6 (should
be the latest). More precisely, I found a problem in the way you compute
normal for a bezier patch (file: bezier.cpp). To say the truth, I think
that it's only a typo, but however... :)

Take a look at the following function (cut & pasted from bezier.cpp):

static DBL determine_subpatch_flatness(VECTOR (*Patch)[4][4])
{
  int i, j;
  DBL d, dist, temp1;
  VECTOR n, TempV;
  VECTOR vertices[4];

  Assign_Vector(vertices[0], (*Patch)[0][0]);
  Assign_Vector(vertices[1], (*Patch)[0][3]);

  VSub(TempV, vertices[0], vertices[1]);

  VLength(temp1, TempV);

  if (fabs(temp1) < EPSILON)
  {
    /*
     * Degenerate in the V direction for U = 0. This is ok if the other
     * two corners are distinct from the lower left corner - I'm sure there
     * are cases where the corners coincide and the middle has good values,
     * but that is somewhat pathalogical and won't be considered.
     */

    Assign_Vector(vertices[1], (*Patch)[3][3]);

    VSub(TempV, vertices[0], vertices[1]);

    VLength(temp1, TempV);

    if (fabs(temp1) < EPSILON)
    {
      return (-1.0);
    }

    Assign_Vector(vertices[2], (*Patch)[3][0]);

    VSub(TempV, vertices[0], vertices[1]);
                                      ^
                                      +---- WRONG!!! Should be: vertices[2],
isn't it?

    VLength(temp1, TempV);

    if (fabs(temp1) < EPSILON)
    {
      return (-1.0);
    }

    VSub(TempV, vertices[1], vertices[2]);

    VLength(temp1, TempV);

    if (fabs(temp1) < EPSILON)
    {
      return (-1.0);
    }
  }
  else
  {
    Assign_Vector(vertices[2], (*Patch)[3][0]);

    VSub(TempV, vertices[0], vertices[1]);
                                      ^
                                      +---- SAME ERROR HERE!!! Should be:
vertices[2]...
    .
    .
}

What you think about it?

Bye,

- Gianluca Arcidiacono (a.k.a. AGPX)


Post a reply to this message

From: Le Forgeron
Subject: Re: I found a bug in povray source code 3.6... Take a look...
Date: 22 Sep 2004 05:03:06
Message: <Xns956C706C5562jgrimbertmeandmyself@203.29.75.35>


> Hello,
> 
> I think to have found some bugs in povray's source code version 3.6
> (should be the latest). More precisely, I found a problem in the way
> you compute normal for a bezier patch (file: bezier.cpp). To say the
> truth, I think that it's only a typo, but however... :)
> 
> Take a look at the following function (cut & pasted from bezier.cpp):
> 

 
>     Assign_Vector(vertices[1], (*Patch)[3][3]);
> 
>     VSub(TempV, vertices[0], vertices[1]);
> 
>     VLength(temp1, TempV);
> 
>     if (fabs(temp1) < EPSILON)
>     {
>       return (-1.0);
>     }
> 
>     Assign_Vector(vertices[2], (*Patch)[3][0]);
> 
>     VSub(TempV, vertices[0], vertices[1]);
>                                       ^
>                                       +---- WRONG!!! Should be:
>                               vertices[2], 
> isn't it?
> 
>     VLength(temp1, TempV);
> 
>     if (fabs(temp1) < EPSILON)
>     {
>       return (-1.0);
>     }
> 

Well, twice the same test, without effective usage of [2], look like a 
quick copy/paste of code which lack the expected correction at the second 
iteration.
So, yes, it seems there is a code error here, and let's blame the typo!

Now, go and make a scene that illustrate it... 

It could be at least interesting to see if we really need a big array of 
4 for Vertices... but that require to make sense of the complete 
function, I do not have time for that.

-- 




l'habillement, les chaussures que le maquillage et les accessoires.


Post a reply to this message

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