POV-Ray : Newsgroups : povray.programming : Lighting.cpp - Assign_Vector used to copy a COLOUR into an RGB Server Time
19 Apr 2024 06:33:54 EDT (-0400)
  Lighting.cpp - Assign_Vector used to copy a COLOUR into an RGB (Message 1 to 5 of 5)  
From: Massimo Valentini
Subject: Lighting.cpp - Assign_Vector used to copy a COLOUR into an RGB
Date: 13 Sep 2002 07:26:45
Message: <3d81cb75$1@news.povray.org>
Looking into the sources of Linux povray (from povuni_s.tgz - version
3.50a)(but the same is in the Win source) I saw two calls to
Assign_Vector that appear to me wrong. On my platform a VECTOR (the size)
occupies 24 bytes, an RGB (the destination) 12, and a COLOUR (the source)
20. Details follow the signature.

If I'm wrong and the code is correct, I think a comment, in the source, 
explaining the thing would be useful.

HTH
Massimo

-> File: lighting.cpp - Line: 5767-5774
      if(fabs(Reflection_Frac)<EPSILON)
      {
        Assign_Vector(reflectivity, Reflection_Min);
      }
      else if (fabs(Reflection_Frac-1.0)<EPSILON)
      {
        Assign_Vector(reflectivity, Reflection_Max);
      }

-> File: lighting.cpp - Line: 5700-5701
void determine_reflectivity(DBL *weight, RGB reflectivity, COLOUR
Reflection_Max,
        COLOUR Reflection_Min, int Reflection_Type, DBL Reflection_Falloff,

(I see this function is called for instance in compute_lighted_texture and
there 'reflectivity' is a COLOUR, but still only 20 bytes)

-> File: lighting.cpp - Line: 35
#include "frame.h"

-> File: frame.h - Line: 902
#define Assign_Vector(d,s)  memcpy((d),(s),sizeof(VECTOR))

-> File: frame.h - Line:812
typedef DBL VECTOR [3];

-> File: frame.h - Line:243
#define DBL double

-> File: frame.h - Line: 816-817
typedef COLC COLOUR [5];
typedef COLC RGB [3];

-> File: frame.h - Line:251
#define COLC float


Post a reply to this message

From: Thorsten Froehlich
Subject: Re: Lighting.cpp - Assign_Vector used to copy a COLOUR into an RGB
Date: 16 Sep 2002 04:02:00
Message: <3d858ff8$1@news.povray.org>
In article <3d81cb75$1@news.povray.org> , "Massimo Valentini" 
<six### [at] inwindit> wrote:

> Looking into the sources of Linux povray (from povuni_s.tgz - version
> 3.50a)(but the same is in the Win source) I saw two calls to
> Assign_Vector that appear to me wrong. On my platform a VECTOR (the size)
> occupies 24 bytes, an RGB (the destination) 12, and a COLOUR (the source)
> 20. Details follow the signature.
>
> If I'm wrong and the code is correct, I think a comment, in the source,
> explaining the thing would be useful.

No, you are correct.  These are indeed bugs.  I would suggest to replace the
Assign_xxx macros in frame.h with something like the inline statements below
to find the remaining cases of the same problem.  It will generate a few
errors when assigning tokens, but those errors are correct and can be fixed
by a simple cast.

    Thorsten


inline DBL *Assign_Vector(DBL *d, DBL *s)
 { return (DBL *)memcpy(d, s, sizeof(VECTOR)); }
inline VECTOR *Assign_Vector(VECTOR *d, VECTOR *s)
 { return (VECTOR *)memcpy(d, s, sizeof(VECTOR)); }

inline DBL *Assign_UV_Vect(DBL *d, DBL *s)
 { return (DBL *)memcpy(d, s, sizeof(UV_VECT)); }
inline UV_VECT *Assign_UV_Vect(UV_VECT *d, UV_VECT *s)
 { return (UV_VECT *)memcpy(d, s, sizeof(UV_VECT)); }

inline DBL *Assign_Vector_4D(DBL *d, DBL *s)
 { return (DBL *)memcpy(d, s, sizeof(VECTOR_4D)); }
inline VECTOR_4D *Assign_Vector_4D(VECTOR_4D *d, VECTOR_4D *s)
 { return (VECTOR_4D *)memcpy(d, s, sizeof(VECTOR_4D)); }

inline COLC *Assign_Colour(COLC *d, COLC *s)
 { return (COLC *)memcpy(d, s, sizeof(COLOUR)); }
inline COLOUR *Assign_Colour(COLOUR *d, COLOUR *s)
 { return (COLOUR *)memcpy(d, s, sizeof(COLOUR)); }

inline COLC *Assign_RGB(COLC *d, COLC *s)
 { return (COLC *)memcpy(d, s, sizeof(RGB)); }
inline RGB *Assign_RGB(RGB *d, RGB *s)
 { return (RGB *)memcpy(d, s, sizeof(RGB)); }


____________________________________________________
Thorsten Froehlich
e-mail: mac### [at] povrayorg

I am a member of the POV-Ray Team.
Visit POV-Ray on the web: http://mac.povray.org


Post a reply to this message

From: ABX
Subject: Re: Lighting.cpp - Assign_Vector used to copy a COLOUR into an RGB
Date: 16 Sep 2002 04:08:26
Message: <i24bouslj0j66aescmr8ss5cbdvduop76n@4ax.com>
On Mon, 16 Sep 2002 10:02:00 +0200, "Thorsten Froehlich" <tho### [at] trfde>
wrote:
> No, you are correct.  These are indeed bugs.

So added to
http://abx.art.pl/pov/patches/patches.php?Key=Bug+Fixes

I wonder if above link could be added to
http://www.povray.org/download/3.5-bugs.php

ABX


Post a reply to this message

From: Massimo Valentini
Subject: Re: Lighting.cpp - Assign_Vector used to copy a COLOUR into an RGB
Date: 16 Sep 2002 14:53:09
Message: <3d862895@news.povray.org>
"Thorsten Froehlich" ha scritto

... I would suggest to replace the
: Assign_xxx macros in frame.h with something like the inline statements
below
: to find the remaining cases of the same problem.  It will generate a few
: errors when assigning tokens, but those errors are correct and can be
fixed
: by a simple cast.
:
:     Thorsten
:
:
: inline DBL *Assign_Vector(DBL *d, DBL *s)
:  { return (DBL *)memcpy(d, s, sizeof(VECTOR)); }
: inline VECTOR *Assign_Vector(VECTOR *d, VECTOR *s)
:  { return (VECTOR *)memcpy(d, s, sizeof(VECTOR)); }
:

Not counting the lack of cast in the parsing code, I found only 
another place doing practically the same. It's in radiosit.cpp 
at line 876:

     Assign_Vector(block->Illuminance, Illuminance);

block->Illuminance is an RGB (float [3])
Illuminance is a COLOUR (float [5])

Massimo


Post a reply to this message

From: Thorsten Froehlich
Subject: Re: Lighting.cpp - Assign_Vector used to copy a COLOUR into an RGB
Date: 16 Sep 2002 16:01:00
Message: <3d86387c@news.povray.org>
In article <3d862895@news.povray.org> , "Massimo Valentini" 
<six### [at] inwindit> wrote:

> Not counting the lack of cast in the parsing code, I found only
> another place doing practically the same. It's in radiosit.cpp
> at line 876:
>
>      Assign_Vector(block->Illuminance, Illuminance);
>
> block->Illuminance is an RGB (float [3])
> Illuminance is a COLOUR (float [5])

Exactly.  I should note that these three have been fixed as of this morning
(GMT).

    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

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