Hi all.

The last couple of days I've been losing my hair over some nasty bugs
in a program I am writing. It was for a project due Sep 3rd. It was
not intended to be a raytracer but at some point in time I figured it
had everything needed except a camera, so I threw one in and voila! :)

Please, pretty please, anyone help me! I am desperate already and I am
almost a week behind schedule. The source is well commented, I hope,
and pretty obvious. I've tried to duplicate POV's functionality in
most places, but obviously failed.

Anyway, the source code is in povray.binaries.programming. If you're
not on Unix you may have to remove the automatic dependency generation
from the makefile (the line with 'sed').

Thanks in advance for any help.


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

Post a reply to this message

P.S. The CNode and CLink classes are irrelevant to the raytracing
part, they are there for my real project. CMesh, too, but it does the
tracing or rays so is a potential bug source, too.


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

Post a reply to this message

P.P.S. Forgot to add it outputs to cout so you will need to redirect
it to a file. The format is PPM (P3).


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

Post a reply to this message

Please... anyone!

What I know for the moment is that:

a) boxes don't render properly. The intersection routine correctly
identifies if a ray intersects a box but returns the wrong depth

b) spheres don't transform at all

c) boxes and spheres disappear when translated. Well, they might not
disappear, but they translate to the void (outside the field of view)
even with a small translation

There're more but I think they are related to the above.

Once again... please help me! I am really stuck, this is stopping my
project and I am badly falling behind schedule. Please... I want to
graduate :)


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

Post a reply to this message

Peter Popov wrote:
> 
> Please... anyone!

I looked slightly code and here are my comments. If I have time, then I
try to look it more.

> What I know for the moment is that:
> 
> a) boxes don't render properly. The intersection routine correctly
> identifies if a ray intersects a box but returns the wrong depth
> 
> b) spheres don't transform at all
Seems like you use one transformation for points, vectors and normals,
but they should be transformed differently. Look POV-Ray source for
details. Generally when transforming vectors, then translations should
not be taken into account and normals should be transformed by inverse
transpose matrix. I guess that this is problem: in CSphere::Intersection
you transform TDirection and 

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.

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

HTH,
Vahur

Post a reply to this message

Thorsten Froehlich wrote:
> 
> In article <dsh2nt03gaj1u2o17rgsiblue403sip45i@4ax.com> , Peter Popov
> <pet### [at] vipbg>  wrote:
> 
> > c) boxes and spheres disappear when translated. Well, they might not
> > disappear, but they translate to the void (outside the field of view)
> > even with a small translation
> 
> In
> 
>     CMatrix CMatrix::operator * (const CMatrix &M1) {
>      unsigned char i, j, k;
>      CMatrix Result = NullMatrix;
> 
>      for (i = 0 ; i < 4 ; i++)
>       for (j = 0 ; j < 4 ; j++)
>        for (k = 0 ; k < 4 ; k++)
>         Result.Elements[i][j] += this->Elements[i][k] * M1.Elements[k][j];
> 
>      return Result;
>     }
> 
> you only return the result but should also copy it into the this-matrix.

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?

Post a reply to this message

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 have to admit that I am not absolutely sure as I usually write operators
like *, /, + outside the class.  I don't have the time to look it up in the
standard right now (nor the time to compile his code), but it would explain
why even simple transformation don't work (as Peter said).  Of course, I
assume Peter is calculating the correct transformation matrix.

    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 <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