Pointer Usage

[Marcus Jacobs]

Before I am flamed, I did search the FAQ for an answer to the question
that I am about to post. Even with a search of the newsgroup archive,
there are so many subjects about pointers I could search for a long
time and not find an answer to my question.

I am currently integrating the Moller-Trumbore ray/triangle
intersection algorithm
(http://www.ce.chalmers.se/old/staff/...aytri/raytri.c) into an
existing raytracer. I have basically plagiarized the original code
with some minor modifications to variable names in order integrate it
into the existing raytracer. Below is the source code to the portion
of the source code that I am modifying. The program compiled under
Cygwin using gcc 3.3.3-2. When I run the program, I receive a
"Segmentati on Segmentation fault (core dumped)" error. After
recompiling the program using the -ggdb compile option, I executed the
program within gdb in order to find out where the problem is
occurring. At this point, it was determined that the Segmentation
fault occurs at the line that reads:

*u = DOT(tvec, pvec);

Does anyone know if this statement is legal? Moller uses this exact
same code and I am assuming that he has successfully run it. The
reason why I question whether or not this satement is legal is because
I am dereferencing the pointer and setting it value to DOT(tvec,
pvec), since this value is calculated on the fly it has no memory
assigned to it and therefore no address. Am I off base? Is the
original Moller-Trumbore code valid?

Marcus




triangleinterse ct(o, r) /* compute intersection with polygonal face
*/
OBJREC *o;
register RAY *r;
{
double rdot; /* direction . normal */
double t; /* distance to intersection */
FVECT pisect; /* intersection point */
register FACE *f; /* face record */
register int i;
double *u, *v, *t;
double det, d, inv_det;
double tvec[3], pvec[3], qvec[3], edge1[3], edge2[3];
VSUB(edge1, VERTEX(f,1), VERTEX(f,0));
VSUB(edge2, VERTEX(f,2), VERTEX(f,0));

/* begin calculating determinant - also used to calculate U
parameter */
VCROSS(pvec, r->rdir, edge2);
/* if determinant is near zero, ray lies in plane of triangle */
det = DOT(edge1, pvec);
if (det < FTINY)
return 0;

/* calculate distance from vert0 to ray origin */
VSUB(tvec, r->rorg, VERTEX(f,0));
/* calculate U parameter and test bounds */
*u = DOT(tvec, pvec);
if (*u < 0.0 || *u > det)
return 0;
/* prepare to test V parameter */
VCROSS(qvec, tvec, edge1);
/* calculate V parameter and test bounds */
*v = DOT(r->rdir, qvec) ;
if (*v < 0.0 || *u + *v > det)
return 0;
*t = DOT(edge2,qvec) ;
inv_det = 1.0/det;
*t *= inv_det;


rdot = -DOT(r->rdir, f->norm);
if (rdot <= FTINY && rdot >= -FTINY) /* ray parallels plane */
t = FHUGE;
//else
// t = (DOT(r->rorg, f->norm) - f->offset) / rdot;
if (t <= FTINY || t >= r->rot) /* not good enough */
return(0);
/* compute intersection */
for (i = 0; i < 3; i++)
pisect[i] = r->rorg[i] + r->rdir[i]* t;
r->rot = t;
VCOPY(r->rop, pisect);
r->rod = rdot;
r->ro = o;
VCOPY(r->ron, f->norm);
r->pert[0] = r->pert[1] = r->pert[2] = 0.0;
r->uv[0] = r->uv[1] = 0.0;
r->rox = NULL;
return(1); /* hit */

[Jack Klein]

Re: Pointer Usage

On 29 Sep 2004 20:05:03 -0700, marcdevon@hotma il.com (Marcus Jacobs)
wrote in comp.lang.c:
[color=blue]
> Before I am flamed, I did search the FAQ for an answer to the question
> that I am about to post. Even with a search of the newsgroup archive,
> there are so many subjects about pointers I could search for a long
> time and not find an answer to my question.
>
> I am currently integrating the Moller-Trumbore ray/triangle
> intersection algorithm
> (http://www.ce.chalmers.se/old/staff/...aytri/raytri.c) into an
> existing raytracer. I have basically plagiarized the original code
> with some minor modifications to variable names in order integrate it
> into the existing raytracer. Below is the source code to the portion
> of the source code that I am modifying. The program compiled under
> Cygwin using gcc 3.3.3-2. When I run the program, I receive a
> "Segmentati on Segmentation fault (core dumped)" error. After
> recompiling the program using the -ggdb compile option, I executed the
> program within gdb in order to find out where the problem is
> occurring. At this point, it was determined that the Segmentation
> fault occurs at the line that reads:
>
> *u = DOT(tvec, pvec);
>
> Does anyone know if this statement is legal? Moller uses this exact
> same code and I am assuming that he has successfully run it. The
> reason why I question whether or not this satement is legal is because
> I am dereferencing the pointer and setting it value to DOT(tvec,
> pvec), since this value is calculated on the fly it has no memory
> assigned to it and therefore no address. Am I off base? Is the
> original Moller-Trumbore code valid?
>
> Marcus
>
>
>
>
> triangleinterse ct(o, r) /* compute intersection with polygonal face
> */[/color]

Prototype style function definitions were added to C 15 years ago.
Why are you still using obsolete code like this?

Also, this code could not have possible compiled. Always copy the
real code from your text editor and paste it as text into the body of
your post.
[color=blue]
> OBJREC *o;
> register RAY *r;
> {
> double rdot; /* direction . normal */
> double t; /* distance to intersection */[/color]

Here you define 't' as a double.
[color=blue]
> FVECT pisect; /* intersection point */
> register FACE *f; /* face record */
> register int i;
> double *u, *v, *t;[/color]

Here you define another object with the name 't' in the same scope as
the one above. This can't possibly compile.

'u' is defined as a pointer to double in the line above. Since it is
an automatic variable and not initialized, its value is indeterminate.
It can point to a double, it does not do so now.
[color=blue]
> double det, d, inv_det;
> double tvec[3], pvec[3], qvec[3], edge1[3], edge2[3];
> VSUB(edge1, VERTEX(f,1), VERTEX(f,0));
> VSUB(edge2, VERTEX(f,2), VERTEX(f,0));
>
> /* begin calculating determinant - also used to calculate U
> parameter */
> VCROSS(pvec, r->rdir, edge2);
> /* if determinant is near zero, ray lies in plane of triangle */
> det = DOT(edge1, pvec);
> if (det < FTINY)
> return 0;
>
> /* calculate distance from vert0 to ray origin */
> VSUB(tvec, r->rorg, VERTEX(f,0));
> /* calculate U parameter and test bounds */
> *u = DOT(tvec, pvec);[/color]

Here is the line that you say is causing your problem. You have an
indeterminate pointer to double. It does not point to a double, it is
an uninitialized pointer. Attempting to dereference the pointer to
read or write memory is undefined behavior. There is every reason for
your program to crash. '*u' is not a double and most likely not
memory that you have a right to access.
[color=blue]
> if (*u < 0.0 || *u > det)
> return 0;
> /* prepare to test V parameter */
> VCROSS(qvec, tvec, edge1);
> /* calculate V parameter and test bounds */
> *v = DOT(r->rdir, qvec) ;[/color]

You'll have the same problem here it you get this far.
[color=blue]
> if (*v < 0.0 || *u + *v > det)
> return 0;
> *t = DOT(edge2,qvec) ;[/color]

....and here.
[color=blue]
> inv_det = 1.0/det;
> *t *= inv_det;
>
>
> rdot = -DOT(r->rdir, f->norm);
> if (rdot <= FTINY && rdot >= -FTINY) /* ray parallels plane */
> t = FHUGE;
> //else
> // t = (DOT(r->rorg, f->norm) - f->offset) / rdot;
> if (t <= FTINY || t >= r->rot) /* not good enough */[/color]

Suddenly, in the two lines above (even though one is commented out),
you are suddenly using 't' like it was a double, not a pointer.
[color=blue]
> return(0);
> /* compute intersection */
> for (i = 0; i < 3; i++)
> pisect[i] = r->rorg[i] + r->rdir[i]* t;
> r->rot = t;
> VCOPY(r->rop, pisect);
> r->rod = rdot;
> r->ro = o;
> VCOPY(r->ron, f->norm);
> r->pert[0] = r->pert[1] = r->pert[2] = 0.0;
> r->uv[0] = r->uv[1] = 0.0;
> r->rox = NULL;
> return(1); /* hit */[/color]

Several places you assign the value of the function/macro DOT to
actual doubles, like 'rdot' and 'det'. Other places you try to assign
the result of whatever twilight zone specified by an indeterminate
pointer, and that's a definite no-no.

Why are 'u', 'v', and 't' defined as pointers to double, and not just
doubles?

This code is frankly unreadable and unmaintainable. Single character
variable names some upper case, pre-ANSI function definitions, and
poor structure make it a nightmare.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.l earn.c-c++

http://www.contrib.andrew.cmu.edu/~ajo/docs/FAQ-acllc.html

[Dag Viken]

Re: Pointer Usage

"Jack Klein" <jackklein@spam cop.net> wrote in message
news:k10nl0d962 luoqinr1oa9ilgi s484uuudq@4ax.c om...[color=blue]
> On 29 Sep 2004 20:05:03 -0700, marcdevon@hotma il.com (Marcus Jacobs)
> wrote in comp.lang.c:
>[color=green]
> > Before I am flamed, I did search the FAQ for an answer to the question
> > that I am about to post. Even with a search of the newsgroup archive,
> > there are so many subjects about pointers I could search for a long
> > time and not find an answer to my question.
> >
> > I am currently integrating the Moller-Trumbore ray/triangle
> > intersection algorithm
> > (http://www.ce.chalmers.se/old/staff/...aytri/raytri.c) into an
> > existing raytracer. I have basically plagiarized the original code
> > with some minor modifications to variable names in order integrate it
> > into the existing raytracer. Below is the source code to the portion
> > of the source code that I am modifying. The program compiled under
> > Cygwin using gcc 3.3.3-2. When I run the program, I receive a
> > "Segmentati on Segmentation fault (core dumped)" error. After
> > recompiling the program using the -ggdb compile option, I executed the
> > program within gdb in order to find out where the problem is
> > occurring. At this point, it was determined that the Segmentation
> > fault occurs at the line that reads:
> >
> > *u = DOT(tvec, pvec);
> >
> > Does anyone know if this statement is legal? Moller uses this exact
> > same code and I am assuming that he has successfully run it. The
> > reason why I question whether or not this satement is legal is because
> > I am dereferencing the pointer and setting it value to DOT(tvec,
> > pvec), since this value is calculated on the fly it has no memory
> > assigned to it and therefore no address. Am I off base? Is the
> > original Moller-Trumbore code valid?
> >
> > Marcus
> >
> >
> >
> >
> > triangleinterse ct(o, r) /* compute intersection with polygonal face
> > */[/color]
>
> Prototype style function definitions were added to C 15 years ago.
> Why are you still using obsolete code like this?
>
> Also, this code could not have possible compiled. Always copy the
> real code from your text editor and paste it as text into the body of
> your post.
>[color=green]
> > OBJREC *o;
> > register RAY *r;
> > {
> > double rdot; /* direction . normal */
> > double t; /* distance to intersection */[/color]
>
> Here you define 't' as a double.
>[color=green]
> > FVECT pisect; /* intersection point */
> > register FACE *f; /* face record */
> > register int i;
> > double *u, *v, *t;[/color]
>
> Here you define another object with the name 't' in the same scope as
> the one above. This can't possibly compile.
>
> 'u' is defined as a pointer to double in the line above. Since it is
> an automatic variable and not initialized, its value is indeterminate.
> It can point to a double, it does not do so now.
>[color=green]
> > double det, d, inv_det;
> > double tvec[3], pvec[3], qvec[3], edge1[3], edge2[3];
> > VSUB(edge1, VERTEX(f,1), VERTEX(f,0));
> > VSUB(edge2, VERTEX(f,2), VERTEX(f,0));
> >
> > /* begin calculating determinant - also used to calculate U
> > parameter */
> > VCROSS(pvec, r->rdir, edge2);
> > /* if determinant is near zero, ray lies in plane of triangle */
> > det = DOT(edge1, pvec);
> > if (det < FTINY)
> > return 0;
> >
> > /* calculate distance from vert0 to ray origin */
> > VSUB(tvec, r->rorg, VERTEX(f,0));
> > /* calculate U parameter and test bounds */
> > *u = DOT(tvec, pvec);[/color]
>
> Here is the line that you say is causing your problem. You have an
> indeterminate pointer to double. It does not point to a double, it is
> an uninitialized pointer. Attempting to dereference the pointer to
> read or write memory is undefined behavior. There is every reason for
> your program to crash. '*u' is not a double and most likely not
> memory that you have a right to access.
>[color=green]
> > if (*u < 0.0 || *u > det)
> > return 0;
> > /* prepare to test V parameter */
> > VCROSS(qvec, tvec, edge1);
> > /* calculate V parameter and test bounds */
> > *v = DOT(r->rdir, qvec) ;[/color]
>
> You'll have the same problem here it you get this far.
>[color=green]
> > if (*v < 0.0 || *u + *v > det)
> > return 0;
> > *t = DOT(edge2,qvec) ;[/color]
>
> ...and here.
>[color=green]
> > inv_det = 1.0/det;
> > *t *= inv_det;
> >
> >
> > rdot = -DOT(r->rdir, f->norm);
> > if (rdot <= FTINY && rdot >= -FTINY) /* ray parallels plane */
> > t = FHUGE;
> > //else
> > // t = (DOT(r->rorg, f->norm) - f->offset) / rdot;
> > if (t <= FTINY || t >= r->rot) /* not good enough */[/color]
>
> Suddenly, in the two lines above (even though one is commented out),
> you are suddenly using 't' like it was a double, not a pointer.
>[color=green]
> > return(0);
> > /* compute intersection */
> > for (i = 0; i < 3; i++)
> > pisect[i] = r->rorg[i] + r->rdir[i]* t;
> > r->rot = t;
> > VCOPY(r->rop, pisect);
> > r->rod = rdot;
> > r->ro = o;
> > VCOPY(r->ron, f->norm);
> > r->pert[0] = r->pert[1] = r->pert[2] = 0.0;
> > r->uv[0] = r->uv[1] = 0.0;
> > r->rox = NULL;
> > return(1); /* hit */[/color]
>
> Several places you assign the value of the function/macro DOT to
> actual doubles, like 'rdot' and 'det'. Other places you try to assign
> the result of whatever twilight zone specified by an indeterminate
> pointer, and that's a definite no-no.
>
> Why are 'u', 'v', and 't' defined as pointers to double, and not just
> doubles?[/color]

I noticed in the original code that u,v, and t were parameters to the
function, presumably to pass back those values to the caller. That not being
the case, these variables should be defined as straight doubles. Note that
the original code at
http://www.ce.chalmers.se/old/staff/...aytri/raytri.c compiles just
fine. One more point about this code: The pointer 'FACE* f' is never
initialized and will cause more problems.
[color=blue]
>
> This code is frankly unreadable and unmaintainable. Single character
> variable names some upper case, pre-ANSI function definitions, and
> poor structure make it a nightmare.[/color]

Well, that's legacy code for you. Just have a look at "Numerical Recipes in
C' (I got edition 2). Who would write maintainable code like that? Yes, I
know several people are questioning some of the advice and algorithms in
that book.

Dag
[color=blue]
> --
> Jack Klein
> Home: http://JK-Technology.Com
> FAQs for
> comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
> comp.lang.c++ http://www.parashift.com/c++-faq-lite/
> alt.comp.lang.l earn.c-c++
> http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html[/color]

[CBFalconer]

Re: Pointer Usage

Dag Viken wrote:[color=blue]
> "Jack Klein" <jackklein@spam cop.net> wrote in message[color=green]
>> marcdevon@hotma il.com (Marcus Jacobs) wrote in comp.lang.c:
>>[/color][/color]
.... snip ...[color=blue][color=green]
>>
>> This code is frankly unreadable and unmaintainable. Single
>> character variable names some upper case, pre-ANSI function
>> definitions, and poor structure make it a nightmare.[/color]
>
> Well, that's legacy code for you. Just have a look at "Numerical
> Recipes in C' (I got edition 2). Who would write maintainable
> code like that? Yes, I know several people are questioning some
> of the advice and algorithms in that book.[/color]

Please snip whatever is not germane to your answer. You included
something like 160 totally unnecessary lines, which increases the
transmission and storage loads everywhere.

--
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[Dag Viken]

Re: Pointer Usage

"CBFalconer " <cbfalconer@yah oo.com> wrote in message
news:415BD81C.1 4013B03@yahoo.c om...[color=blue]
> Dag Viken wrote:[color=green]
> > "Jack Klein" <jackklein@spam cop.net> wrote in message[color=darkred]
> >> marcdevon@hotma il.com (Marcus Jacobs) wrote in comp.lang.c:
> >>[/color][/color]
> ... snip ...[color=green][color=darkred]
> >>
> >> This code is frankly unreadable and unmaintainable. Single
> >> character variable names some upper case, pre-ANSI function
> >> definitions, and poor structure make it a nightmare.[/color]
> >
> > Well, that's legacy code for you. Just have a look at "Numerical
> > Recipes in C' (I got edition 2). Who would write maintainable
> > code like that? Yes, I know several people are questioning some
> > of the advice and algorithms in that book.[/color]
>
> Please snip whatever is not germane to your answer. You included
> something like 160 totally unnecessary lines, which increases the
> transmission and storage loads everywhere.[/color]

Sorry about my bloated email,

Do you have a comment on the issue?

Dag

[Dan Pop]

Re: Pointer Usage

In <415D3486.E158A C6@yahoo.com> CBFalconer <cbfalconer@yah oo.com> writes:
[color=blue]
>idea of scope. If I have not made it available on my download
>page, I can do so (in x86 executable form only).[/color]
^^^^^^^^^^^^^^^ ^^^^^^^^^^^^
Does this mean that it can be fed to any x86-based system and it will
happily execute it?

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Dan.Pop@ifh.de
Currently looking for a job in the European Union

[CBFalconer]

Re: Pointer Usage

Dan Pop wrote:[color=blue]
> CBFalconer <cbfalconer@yah oo.com> writes:
>[color=green]
> >idea of scope. If I have not made it available on my download
> >page, I can do so (in x86 executable form only).[/color]
> ^^^^^^^^^^^^^^^ ^^^^^^^^^^^^
> Does this mean that it can be fed to any x86-based system and it
> will happily execute it?[/color]

Assuming it supplies or simulates a suitable subset of the system
calls of MsDos, yes. Does this mean you want it, as I find it is
not presently mounted?

--
Chuck F (cbfalconer@yah oo.com) (cbfalconer@wor ldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home .att.net> USE worldnet address!

[Dan Pop]

Re: Pointer Usage

In <415D8531.95D75 42F@yahoo.com> CBFalconer <cbfalconer@yah oo.com> writes:
[color=blue]
>Dan Pop wrote:[color=green]
>> CBFalconer <cbfalconer@yah oo.com> writes:
>>[color=darkred]
>> >idea of scope. If I have not made it available on my download
>> >page, I can do so (in x86 executable form only).[/color]
>> ^^^^^^^^^^^^^^^ ^^^^^^^^^^^^
>> Does this mean that it can be fed to any x86-based system and it
>> will happily execute it?[/color]
>
>Assuming it supplies or simulates a suitable subset of the system
>calls of MsDos, yes.[/color]

There was no mention of MSDOS in your previous post, was it?
[color=blue]
>Does this mean you want it, as I find it is not presently mounted?[/color]

Nope, merely pointing out that the string "x86 executable form" doesn't
make much sense.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Dan.Pop@ifh.de
Currently looking for a job in the European Union