POV-Ray : Newsgroups : povray.programming : Porting away from VECTOR Server Time
29 Mar 2024 04:33:05 EDT (-0400)
  Porting away from VECTOR (Message 1 to 6 of 6)  
From: Nicolas Alvarez
Subject: Porting away from VECTOR
Date: 7 Mar 2014 21:29:53
Message: <531a80a1$1@news.povray.org>
I'm seeing a few things in the code that were deprecated, or were partially 
replaced. For example, VECTOR is a plain array of three doubles, and there 
are global C-like functions to work with them; but there's also a Vector3d 
class. Is the intention to eventually port all uses of VECTOR to Vector3d?

(By the way, why does Vector3d have an array instead of just three members?)


Post a reply to this message

From: Le Forgeron
Subject: Re: Porting away from VECTOR
Date: 8 Mar 2014 03:23:22
Message: <531ad37a$1@news.povray.org>
Le 08/03/2014 03:29, Nicolas Alvarez nous fit lire :
> (By the way, why does Vector3d have an array instead of just three members?)
> 
Just my guess: you cannot loop over members.


Post a reply to this message

From: Nicolas Alvarez
Subject: Re: Porting away from VECTOR
Date: 8 Mar 2014 13:30:50
Message: <531b61da@news.povray.org>
Nicolas Alvarez wrote:
> I'm seeing a few things in the code that were deprecated, or were
> partially replaced. For example, VECTOR is a plain array of three doubles,
> and there are global C-like functions to work with them; but there's also
> a Vector3d class. Is the intention to eventually port all uses of VECTOR
> to Vector3d?

Oh, I see clipka already did most of this porting in the 'refactor' git 
branch :)


Post a reply to this message

From: clipka
Subject: Re: Porting away from VECTOR
Date: 24 May 2014 13:53:45
Message: <5380dca9@news.povray.org>
Am 08.03.2014 09:23, schrieb Le_Forgeron:
> Le 08/03/2014 03:29, Nicolas Alvarez nous fit lire :
>> (By the way, why does Vector3d have an array instead of just three members?)
>>
> Just my guess: you cannot loop over members.

More to the point, you can't index into members. Some internal code is 
optimized in such a way that it needs to give one of the axes special 
treatment (e.g. the axis closest to the direction in which a vector is 
facing); in such cases, index variables are used for the axes rather 
than hard-coded X=0, Y=1 and Z=2.


Post a reply to this message

From: Nicolas Alvarez
Subject: Re: Porting away from VECTOR
Date: 31 May 2014 23:02:24
Message: <538a97c0@news.povray.org>
Nicolas Alvarez wrote:
> Nicolas Alvarez wrote:
>> I'm seeing a few things in the code that were deprecated, or were
>> partially replaced. For example, VECTOR is a plain array of three
>> doubles, and there are global C-like functions to work with them; but
>> there's also a Vector3d class. Is the intention to eventually port all
>> uses of VECTOR to Vector3d?
> 
> Oh, I see clipka already did most of this porting in the 'refactor' git
> branch :)

Are you planning to merge that back to master anytime soon?


Post a reply to this message

From: clipka
Subject: Re: Porting away from VECTOR
Date: 15 Jun 2014 06:03:47
Message: <539d6f83$1@news.povray.org>
Am 01.06.2014 05:02, schrieb Nicolas Alvarez:
> Nicolas Alvarez wrote:
>> Nicolas Alvarez wrote:
>>> I'm seeing a few things in the code that were deprecated, or were
>>> partially replaced. For example, VECTOR is a plain array of three
>>> doubles, and there are global C-like functions to work with them; but
>>> there's also a Vector3d class. Is the intention to eventually port all
>>> uses of VECTOR to Vector3d?
>>
>> Oh, I see clipka already did most of this porting in the 'refactor' git
>> branch :)
>
> Are you planning to merge that back to master anytime soon?

Done that two days ago.

However, the 'refactor' branch is once again ahead already, and I can 
now proudly announce that the last remaining references to VECTOR have 
finally been squashed yesterday. (Well, kind of - it was actually some 
hours after midnight, which leaves me kinda tired today, but that's 
perfectly okay :)).

*Hooray!*

Next steps: Getting rid of UV_VECT, and eliminating COLOUR from the 
back-end. Both will require major refactoring of the blend map handling, 
which might turn out to be a tough nut to crack.


Post a reply to this message

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