Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[cre8orexpert]

Hey dude, it's great to see your engine progressing  . I will start to help you again soon, not so soon, right now i'm studying tcp/udp to able to build multiplayer games (including an online card game, that will certainly be my first completed game, i hope ). So give your best and don't forget to rest! .

Off-topic: I was a bit worried about you, but it looks like both your personality and thinking is intact  .

[cooldude234]

lol, why would you say that, I'm not the one that went missing of the face of the earth

[Thanos]

RTI V3.
I changed the equations. This solves a lot of bugs, and also gives a simpler code.
If it still makes a bug, give me your input and I'll try to reproduce it.


EDIT 27/2/2013: Another bug. DOH
Removed attachment, look for v4.

[cre8orexpert]

Looking at the code and equations, it's well written and should work now. In case this doesn't work, you should give a look at how you're constructing the ray ie: converting mouse (window) coords to 3d. Mixing degrees and radians can also lead to errors and wrong output.

PS: I didn't test your code Thanos, i've just formatted my machine and my super 128k dial-down disconnection makes me unable to download a compiler  .

[cooldude234]

Hey your back cre8oristhe (I'm still going to call you that  )

Anyways, I sent you my code through PM thanos, also I noticed an error in my code, fixed it and it didn't change anything   (I had    y5 = (Vert2.y+Vert2.y)/2; intead of y5 = (Vert2.y+Vert3.y)/2;)

And I still don't really understand any of this code, like what are the triangles midways?
What is half of this code even doing, I have no clue?

Also I would like to add, that the collision also doesn't work on 90 degree angles as well, it's just less noticeable.
What happens is around the edges of where 2 lines on the triangle meet (at the vertices) you can just go straight through them, but at the center of the triangle you can't.

[cre8orexpert]

Lol (i hate you ), i don't know of this will change anything, but try normalizing the ray direction (Ray2 in your code dude). Also PM me with the code you're using to build the ray.

[cooldude234]

I'm just using two points for my ray, as shown in my code. From that you can could make a ray and normal direction from it if you really wanted to.
So all I'm doing to do build the ray is define two points in 3 dimensions (x,y,z), those two points form a line, or in this case a ray.

try normalizing the ray direction

That wont do any good, because then you'd be colliding with stuff way after you went through it.

[cre8orexpert]

Got it!. I'll take another look here, it would help a lot to have a compiler .

[Thanos]

When you say you don't understand half of my code, you mean the first half (finding the collision point) or the second half (checking if it's in the triangle)?

Also, did you try rti v3 and it still doesn't work? Because I think it works ok for me (see the example file in the zip).

I'm checking your code now.

EDIT: See image, red are what I call 'points at corners', blue what I call 'points at midways' (actually called midpoints   )
...and, what I call 'internal product' is uh, the dot product.

EDIT 2: Ok, I think I start to see what is different between the codes. Here:

Code: [Select]

if ( (Dist1 * Dist2) >= 0.0f)
{
// line doesn't cross the triangle.
I thought you meant that the two points define an infinite line. It now seems you meant just the line part between them, right?

EDIT 3: Wait a minute... you don't have to invert x,z, do you? I think it should work without problem anyway.
Can you give me an input to test? (one you know it doesn't work)

[cooldude234]

When you say you don't understand half of my code, you mean the first half (finding the collision point) or the second half (checking if it's in the triangle)?

I refer to all of it, although I am using my code for finding the collision point only because I understand it and I know it works.

Also, did you try rti v3 and it still doesn't work? Because I think it works ok for me (see the example file in the zip).

Yes I did try it, still doesn't work.

I thought you meant that the two points define an infinite line. It now seems you meant just the line part between them, right?

Well I'm getting the collision point on a line that is formed between two points (so I can do area ray casting, I.e. a ray can be "fired" and take time to reach from one end of the world to the other by moving)
But that shouldn't affect checking to see if the collision point belongs inside the triangle should it?

EDIT 3: Wait a minute... you don't have to invert x,z, do you? I think it should work without problem anyway.

well for some reason I had to invert the x and z because what visually was being shown (the triangle) and where the collision was occurring was on the separate sides from the words origin. However I don't see how that would effect the math, only the outcome.

Can you give me an input to test? (one you know it doesn't work)

What do you mean input to test? Like compiled code, like an exe?

[Thanos]

What do you mean input to test? Like compiled code, like an exe?

No, no... just a test case that produces wrong results, for example something like, triangle points: (0,0,0), (5,0,0), (0,0,5) line: (1,-1,1), (1,1,1). I can put your input in the debugger and see where it stops working correctly.

[cooldude234]

well I have the vertices of the two triangles at

   Vertex1.x = 0;
   Vertex1.y = 0;
   Vertex1.z = 0;

   Vertex2.x = 6;
   Vertex2.y = 0;
   Vertex2.z = 0;

   Vertex3.x = 6.3;
   Vertex3.y = 9.1;
   Vertex3.z = 5;

   Vertex12.x = 5;
   Vertex12.y = 0;
   Vertex12.z = 0;

   Vertex22.x = 0;
   Vertex22.y = 0;
   Vertex22.z = 0;

   Vertex32.x = 5;
   Vertex32.y = 0;
   Vertex32.z = -5;

It's failing (like I said earlier) near vertices, it works if your dead on with the triangle but not if your close to the vertices.

EDIT: I would suspect floating point inaccuracies could be the cause, but with the size the each triangle, and considering the precision of a 32 bit floating point (which can store up to 7 digits after the decimal) this cannot be the case.

[Thanos]

Oh, oh I found the bug. I'll post a new version once I fix it. Thanks for the input, it helped.

(If you're curious, rti3 code was made to work only with equilateral triangles... [What on earth was I thinking?] Anyway, I'll have news soon.)

[Thanos]

Ok, fixed...
cooldude234, I PM'd you with your fixed code.  

For the rest, rti v4 is attached below.

(Work this time... plz...  )

[cooldude234]

okay a bunch of stuff has been changed as I can see.
Just a couple of questions, I might do some debugging my self to get another view point on this,
but which is the faster method for getting the plane collision?
Also what method are you using (I really don't understand any the code too much), is it this method you are using?
http://geomalgorithms.com/a06-_intersect-2.html

Right now I'm trying to figure out how a, b and c are being represented as the plane, because the math that you used to make the plane defined by the triangle is exactly the same as the code I used for finding the normal of the triangle (by getting the cross-product). But you cannot have a plane with the normal, you need a point as well to define the position (I use the first vertices read because its quick and easy, it doesn't matter which it is anyways).

But none the less thanks for the code, once I figure out what numbers need to be used, I'll get it in my code and test it out, hopefully it will work.

If you're curious, rti3 code was made to work only with equilateral triangles... [What on earth was I thinking?]

LOL, yea I don't ever think a equilateral only collision algorithm is going to be useful to me