In article <3b71858f@news.povray.org> , "Thorsten Froehlich" 
<tho### [at] trfde> wrote:

> In article <3B718365.C2F57AE1@comtrade.ee> , Vahur Krouverk
> <vkr### [at] comtradeee>  wrote:
>
>> Hmm, are you sure in it? Generally such expression
>> x=y*z;
>> should not modify y or z, but your proposal will change y. I guess that
>> you confuse operator * with operator *= in this case?

I check.  Of course you are right, I confused it...

I guess I should concentrate or not answer a question.  Sorry for the
confusion, Peter!  thanks for noticing my mistake Vahur!

I canceled my previous two posts.  Only the following remark is still valid
and already contradicts what I said earlier in the same post because if
VCross inside the class would modify the object, VCross outside the class
would be a different function, which it is not...

>>
Further, you define some functions in the class and then again outside, for
example VCross.

Also, I would strongly recommend to normalise vectors only when necessary.
sqrt is not only slow, but if you scale the vector a lot this way (you do so
for nearly every vector operation) the error will build up and might be
significant in the end.  At least you should make Update an inline function
to not waste more time on yet another function call.
<<

    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

>Further, you define some functions in the class and then again outside, for
>example VCross.

This is intentional. It is for convenience, when you want the result
of VCross or VTransform to be stored in the same vector.

>Also, I would strongly recommend to normalise vectors only when necessary.

I will look into this. So far I only want to make it work :)

>sqrt is not only slow, but if you scale the vector a lot this way (you do so
>for nearly every vector operation) the error will build up and might be
>significant in the end.

Point taken.

>At least you should make Update an inline function
>to not waste more time on yet another function call.

This is up to the compiler, I guess. I will do some performance tests
when I fix them nasty bugs.


Peter Popov ICQ : 15002700
Personal e-mail : pet### [at] vipbg
TAG      e-mail : pet### [at] tagpovrayorg

Post a reply to this message

>Seems like you use one transformation for points, vectors and normals,

Thanks, point taken. Makes sense :)

>Other problem, which I found, is in transformation code: e.g. in method
>CVector::VInverseTransform you modify first x value of vector, then use
>this modified value to calculate y and then use modified x and y to
>calculate z. This leads to wrong result, of course. Instead you should
>cache current values for x, y and z and then calculate new values by
>using these cached values.

*slaps head*

Of course! OMG this is such a blatantly stupid mistake! Thanks for
pointing it out.

>Correct these errors and I guess that most transformation problems will
>disappear.

Unfortunately, no. Even if I remove any and all transformation code
from CBox::Intersect (or CSphere::Intersect) and only use
untransformed primitives, they render incorrectly.


Peter Popov ICQ : 15002700
Personal e-mail : pet### [at] vipbg
TAG      e-mail : pet### [at] tagpovrayorg

Post a reply to this message

"Thorsten Froehlich" <tho### [at] trfde> wrote in message
news:3b71858f@news.povray.org...
>
>  I usually write operators like *, /, + outside the class.

    I've seen this done in many places, but have never understood why -
these operations are properties of the class and therefore, surely, the
correct place for them to reside is within the class ?

--
Scott Hill.
Software Engineer.
E-Mail        : sco### [at] innocentcom
Pandora's Box : http://www.pandora-software.com

*Everything in this message/post is purely IMHO and no-one-else's*

Post a reply to this message

In article <52a3ntc43mlkpp85jvf1g18pmian504003@4ax.com> , Peter Popov 
<pet### [at] vipbg>  wrote:

> Unfortunately, no. Even if I remove any and all transformation code
> from CBox::Intersect (or CSphere::Intersect) and only use
> untransformed primitives, they render incorrectly.

You are scaling vectors to unit length in some places.  You should really
not have such side effects in your code.  If you remove it at least
debugging should be easy.  After all, a sphere/ray intersection isn't that
hard to debug if you are sure your vectors work without side effects.


    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

In article <3b71c0ef@news.povray.org> , "Scott Hill" <nos### [at] nospamthanks>
wrote:

>     I've seen this done in many places, but have never understood why -
> these operations are properties of the class and therefore, surely, the
> correct place for them to reside is within the class ?

It is strongly suggested by Stroustrup in his books.  He never really
explains why it is so beneficial.  Most of the STL follows it.  I can't
think of many (non-philosophical) reasons that would make a huge difference
(i.e. in speed), but in general such code is much easier to comprehend and
that is enough for me to use it...

    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

In article <da53ntov8fnpb02dcs15kgcfm3ompe7u9e@4ax.com> , Peter Popov 
<pet### [at] vipbg>  wrote:

> This is up to the compiler, I guess. I will do some performance tests
> when I fix them nasty bugs.

No, you should define the function as "inline".  A compiler doesn't have to
inline functions automatically, and many compilers won't except you
explicitly tell them to use auto-inlining.

    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

Thorsten Froehlich <tho### [at] trfde> wrote:
: No, you should define the function as "inline".  A compiler doesn't have to
: inline functions automatically, and many compilers won't except you
: explicitly tell them to use auto-inlining.

  Note that a compiler doesn't have to inline anything even if "inline" is
used.

  Sometimes a function _can't_ be inlined even if you wanted.

-- 
#macro N(D,I)#if(I<6)cylinder{M()#local D[I]=div(D[I],104);M().5,2pigment{
rgb M()}}N(D,(D[I]>99?I:I+1))#end#end#macro M()<mod(D[I],13)-6,mod(div(D[I
],13),8)-3,10>#end blob{N(array[6]{11117333955,
7382340,3358,3900569407,970,4254934330},0)}//                     - Warp -

Post a reply to this message

Scott Hill wrote:
> 
> "Thorsten Froehlich" <tho### [at] trfde> wrote in message
> news:3b71858f@news.povray.org...
> >
> >  I usually write operators like *, /, + outside the class.
> 
>     I've seen this done in many places, but have never understood why -
> these operations are properties of the class and therefore, surely, the
> correct place for them to reside is within the class ?
> 
The reason for this is notation convenience. Consider class Complex with
operators *, /, +, - defined in class scope
class Complex{
  public:
    const Complex operator *(const Complex & c1){
      //...
    }

};
Now you can do this:
Complex c1, c2;
c1=c2*5;
but can't do this:
c1=5*c2;
as there is no operator *(const Complex & c) for type int. If you define
it outside of class:
const Complex operator *(const Complex &c1, const Complex &c2);
and have constructor for Complex, which allows object creation from int,
then second statement compiles OK.

Post a reply to this message

SLAP! <fx: hand slaps on forehead>
    BING! <fx: lightbulb illuminates over head>

    I was sure there must be some reason for it - I guess I've just never
come across that situation/problem... Makes perfect sense... Cool... Another
little gem for my personal 'good OOP practices' list... Cheers...

--
Scott Hill.
Software Engineer.
E-Mail        : sco### [at] innocentcom
Pandora's Box : http://www.pandora-software.com

*Everything in this message/post is purely IMHO and no-one-else's*

Post a reply to this message