• 13
• 15
• 27
• 9
• 9

# [fixed]this has me stumped

This topic is 3878 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

I have a problem with one of the primitives in my collision detection system. I want to have three lines attached to each triangle, going around the vertices. one from vertex 0 to vertex 1 one from vertex 1 to vertex 2 one from vertex 2 to vertex 0 When I draw the lines, to check they are in the correct place, the first two work but the last one is drawn wrong. It starts at vertex 2 but doesn't end at vertex 0. Here is a screenie: The small line in the right bottom corner is supposed to be there. Its a line segment I'm testing for intersection with the triangle. That works just fine. Here is the source code to build the triangle:

void triangle::build(g_vector V1, g_vector V2, g_vector V3)
{
vertices = (g_vector *)malloc(sizeof(g_vector)*3);
lines = (line_segment *)malloc(sizeof(g_vector)*3);
num_vertices=3;
vertices[0]=V1;
vertices[1]=V2;
vertices[2]=V3;

plane.build(V1,V2,V3);

lines[0].build(vertices[0],vertices[1]-vertices[0]);
lines[1].build(vertices[1],vertices[2]-vertices[1]);
lines[2].build(vertices[2],vertices[0]-vertices[2]);
contacted = 0;
r=0; g=1; b=0;
};


and to draw a triangle:
void triangle::draw()
{
if(contacted)
glColor3f(1, 0, 0);
else
glColor3f(r, g, b);

glBegin(GL_POLYGON);
for(uint i = 0; i < num_vertices; i++){
float x,y,z;
p.normal.get_vector(x,y,z);
glNormal3f(x,y,z);
glVertex3f(vertices.x,vertices.y,vertices.z);
};
glEnd();

lines[0].draw();
lines[1].draw();
lines[2].draw();

};


anybody see what i did wrong? [Edited by - speciesUnknown on August 5, 2007 12:23:22 AM]

##### Share on other sites
I dump the lines to the console.
Format is:

start of line1
start of line plus direction of line1

start of line2
start of line plus direction of line2

start of line3
start of line plus direction of line3

-8.600000,-1.000000,-11.300000
3.600000,0.000000,3.000000

3.600000,0.000000,3.000000
10.000000,2.600000,-6.900000

10.000000,2.600000,-6.900000
-8.600000,-1.000000,-6.900000

They should meet at the end.

##### Share on other sites
I assume this is C++ code and that g_vector is a class (since you have called member functions from it). In that case you should not be using malloc, since it won't call any constructors, you should use:

vertices = new g_vertex[3];

(which is easier to read and understand anyway :P )

This is probably not what is causing the error, but it may well be (without more details of what g_vector does in its constructor, if anything, it's hard to say).

##### Share on other sites
lines = (line_segment *)malloc(sizeof(g_vector)*3);

I think your error is trying to allocate enought space for three g_vector instead of three line_segment making you play in memory where you shouldn't :P

And sphen_lee is also right about the way you create your objects. When using a class, you should use the "new" operator to make sure the constructor is called.

##### Share on other sites
g_vector doesn't have a constructor. Neither do my other primitives. They get defined and destroyed within function scope, particularly the vector class which is used within statement scope, for example:

distance_to_target=(this.position-target.position).get_length();

I've overloaded the appropriate operators for vectors and matrices.

Is that a problem? I often use classes in this way. As a result, I prefer to use malloc when defining an array of such data types. I use new when I am dealing with pointers, because as you say, its easier to read.

It contains junk data until its initialized, but that only causes a problem if I don't initialize it, in the same way as an uninitialized int.

Here is the build method for my line_segment class. It doesn't have a constructor either.

void line_segment::build(g_vector s, g_vector e){	start = s;	direction = e;};

I'm initializing them in the triangle build function, as pasted in my original post.

g_vectors seem to work perfectly. I've been using the same class since I wrote it 18 months ago. But, my system of not using constructors might be the problem. I've never really thought about it before.

##### Share on other sites
Quote:
 Original post by Frounklines = (line_segment *)malloc(sizeof(g_vector)*3);I think your error is trying to allocate enough space for three g_vector instead of three line_segment making you play in memory where you shouldn't :P

:-/

Never again will I use copy and paste.

If you were not so far away I'd buy you a pint. Thanks.

##### Share on other sites
Quote:
 Original post by speciesUnknownHere is the build method for my line_segment class. It doesn't have a constructor either.*** Source Snippet Removed ***
It is probably better to use a constructor for that. You can still have a parameterless constructor that does nothing if you're worried about data being initialised needlessly and then changed.

void line_segment::line_segment(g_vector s, g_vector e) : start(s), direction(e){}void line_segment::line_segment(){}

##### Share on other sites
Thanks,
I started another thread to discuss my policy of not always using constructors,

http://www.gamedev.net/community/forums/topic.asp?topic_id=458567

and I've come to the same conclusion.

##### Share on other sites
A triangle always has three vertices (by definition); why would you be doing any dynamic allocation at all (or for that matter, storing a vertex count)?

In fact, what your "build" functions are doing is exactly what the constructors should be doing. And since it has to happen sometime, you're not going to sell me any performance arguments :P (But you *do* know about initialization lists, yes? Oh, and "contacted" sure sounds like it should be a boolean value...)

And what's a g_vector, anyway?

triangle::triangle(const vector& V1, const vector& V2, const vector& V3) :                   r(0), g(1), b(0), contacted(false), plane(V1, V2, V3) {	vertices[0] = V1;	vertices[1] = V2;	vertices[2] = V3;		lines[0] = line(V1, V2 - V1);	lines[1] = line(V2, V3 - V2);	lines[2] = line(V3, V1 - V3);}

(And that's ignoring potential deeper design problems, such as redundancy in the stored data...)