Print

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

[Malus]

After hours reading mathematics, physics, and programming articles about collision resolution, I still can't find a good way to solve that "seam" problem where a bounding box gets stuck on the corner of adjacent rectangles it's colliding with. I even know what causes the problem, yet I'm still no closer to an answer.

Hmm, could you be more specific? Are you having issues with bounding boxes actually intersecting, preventing all movement? If you're using floating point positions, make sure to use epsilons or you'll be tearing your hair out. I'm also curious what your code looks like.

[Gatleos]

After hours reading mathematics, physics, and programming articles about collision resolution, I still can't find a good way to solve that "seam" problem where a bounding box gets stuck on the corner of adjacent rectangles it's colliding with. I even know what causes the problem, yet I'm still no closer to an answer.

Hmm, could you be more specific? Are you having issues with bounding boxes actually intersecting, preventing all movement? If you're using floating point positions, make sure to use epsilons or you'll be tearing your hair out. I'm also curious what your code looks like.

Here, I found a picture in a stack exchange question:

Spoiler (click to show/hide)

Basically, I find out which axis has the smallest intersection, and move the bounding box back along that axis so it's not intersecting. But when I'm on top of two tiles which are adjacent like this, and I move to the side while being affected by gravity, it's possible that the smallest intersection is horizontal on one of the tiles. There's no easy way to handle this.

[miauw62]

You could run your collision detection using theoretical coordinates and only move the block if those are possible, instead of moving, checking and then resolving.

[Malus]

OK yeah, I see what the issue is now. You need to do the collision detection by ray tracing the velocity vector, finding the nearest collision intersection, then zeroing the velocity along that normal and ray tracing the new velocity vector (once again checking for collisions).

Your example shouldn't happen under this scheme -- the box is already colliding with the ground on the y-axis so any ray trace would find that immediately, zero your y velocity, then try to move you along the x-axis instead.

[MagmaMcFry]

OK yeah, I see what the issue is now. You need to do the collision detection by ray tracing the velocity vector, finding the nearest collision intersection, then zeroing the velocity along that normal and ray tracing the new velocity vector (once again checking for collisions).

Your example shouldn't happen under this scheme -- the box is already colliding with the ground on the y-axis so any ray trace would find that immediately, zero your y velocity, then try to move you along the x-axis instead.

The major problem with that method is that you can't walk uphill.

[Malus]

The major problem with that method is that you can't walk uphill.

Not necessarily. It's pretty easy to adapt to allow ramps/slopes, it just changes the math around a bit. When you find the normal of the collision edge, you need to transpose the velocity vector onto it (essentially, construct a new coordinate system where the surface normal is 'y' , then transform/project the velocity vector onto that coordinate system and zero like usual). It's the same math you'd use for rotating/scaling a bitmap. We even have a name for this operation: it's called a dot product.

I'm probably using some terms wrong (it's been a while since I've done any reading on this) but hopefully that's enough to point in the right direction.

[3man75]

Spoiler (click to show/hide)

#include <iostream>
#include <string>
#include <iomanip>
#include <fstream>

using namespace std;

int main()
{
   ifstream infile;
   ofstream outfile;


   string firstName;
   string lastName;
   double testScore;

   //open the file

   infile.open("testScore.txt");

      //output file
      outfile.open("testScore2TWO2.txt");

   outfile << fixed << showpoint << setprecision(2);

   while (infile)
   {
      infile >> firstName >> lastName >> testScore;
      


      outfile << left << setw(12) << firstName << setw(12) << lastName
         << right << setw(4) << testScore << endl;
      //Formating output
   }

   infile.close();
   outfile.close();
   
   return 0;
}

When the information is exported onto testscore2 it does samantha coy twice.

[Reelya]

there you go again with being vague. How the fuck are we supposed to know where "samantha coy" comes in the file? How are you expecting us to help you by telling us about "samantha coy". Try thinking before you post. I've got the impression from previously that you don't really read what we write, and you just post bullshit which lacks even the most basic information for us to work out what your problem is.

I'd guess what your problem is but I couldn't be bothered to go through another series of exchanges where you keep going "oh no that's not quite what I meant".

[3man75]

Samantha coy and the other names come from another file of another file that is test score. Basically test score inputs info and then outputs to testscore2.

For some reason when the information from the original is exported to the second it copies one of the names. Sorry I wasn't thinking when I set up the question.

there you go again with being vague. How the fuck are we supposed to know where "samantha coy" comes in the file? How are you expecting us to help you by telling us about "samantha coy". Try thinking before you post. I've got the impression from previously that you don't really read what we write, and you just post bullshit which lacks even the most basic information for us to work out what your problem is.

I'd guess what your problem is but I couldn't be bothered to go through another series of exchanges where you keep going "oh no that's not quite what I meant".

Fuck you to bro. NVM.

[Reelya]

Goddamnit, i already KNEW she's a name from the file because that's fucking completely obvious, a three year old can work that bit out, so it's a waste of time for you to mention it. We're not retarded here.

You're still not giving us any information we can use. The fucking name "samantha coy" IS NOT THE IMPORTANT INFORMATION.

Where in the file does she appear? At the start, at the end, in the middle etc?

[3man75]

but where in the file does samantha coy appear? Goddamnit, i already KNEW she's a name from the file because that's fucking obvious, so it's a waste of time for you to mention it. We're not retarded here.

You're still not giving us any information we can use. The fucking name "samantha coy" IS NOT THE IMPORTANT INFORMATION.

Where in the file does she appear? At the start, at the end, in the middle etc?

What I'm trying to say is this: For some reason, a part of the file duplicates when it's exported instead of just giving me the information once. It's suppose to give a first name, last name, and a number/testscore.

EX of what I should get: Input John Jay 10

     Output John Jay 10.

However, I get the output of John Jay 10 twice. I'm not sure why because I'm asking it to just send it once.

I just learned how to do infile and outfile today and the concept is very new to me.

[Reelya]

so it's not just "doing samantha coy twice", it's repeating every single line twice? Do you see how confusing your vagueness is? you said it just did Samantha Coy twice, nothing about doing every name twice.

EDIT: I tested it and it does in fact print only the last line twice. Which makes me even more annoyed at you because I asked specifically for clarification about that specific issue, and you only made it more confusing. I have to ask, are you doing this on purpose?

Relace the while statement with:

while (!infile.eof())

Case closed. No more chatting.

[Gatleos]

OK yeah, I see what the issue is now. You need to do the collision detection by ray tracing the velocity vector, finding the nearest collision intersection, then zeroing the velocity along that normal and ray tracing the new velocity vector (once again checking for collisions).

Your example shouldn't happen under this scheme -- the box is already colliding with the ground on the y-axis so any ray trace would find that immediately, zero your y velocity, then try to move you along the x-axis instead.

Alright, so lemme try to work this out. I do some raytracing with the object's velocity vector, find the first thing it intersects and the normal of the collision (which would just be a horizontal or vertical line with AABBs, regardless of the ray angle, I think?), then zero the vector along that normal I calculated. So in the case of moving down and to the right, my vector would end up pointing straight to the right instead. Then I repeat until there are no intersections with the ray.

Is that right? Sorry, I'm very rusty on vector math, and physics in general. That's probably why this is such a big problem in the first place.

Also, I assume that zeroing the vector along an axis involves vector multiplication (dot product or cross product), but I'm not sure of the exact operations I should be doing here. It would be extremely useful if I could get this working with slopes.

EDIT: also I just realized I don't even know where to trace the ray from. Should it be from the AABB's corner which is pointing in the direction of the velocity vector? This might be more difficult than I thought.

[jaked122]

So that tree implementation is more broken than I thought, even while not using nonstantard implementation bits of the STL.

The tree is perfectly formed. It's self balancing. But iterating in order is broken after deletion. And for the life of me, I can't figure out why. It can find the elements, even when they are iterated over in the wrong order, but I still don't get it.


Also the AA tree is fun. So much easier than red-black trees.


Also I think the name for what you guys are talking about is either "Predictive Collision" or "Speculative Collision". I'm pretty sure it's the first one, but I don't know.

[i2amroy]

I'd guess what your problem is but I couldn't be bothered to go through another series of exchanges where you keep going "oh no that's not quite what I meant".

While I think that Reelya might be overreacting a bit here, I do kinda sympathize with what they are getting at. We'll happily help you with your problems 3man75, but if you want us to debug something you need to be very specific about exactly what your program is supposed to be doing and what it isn't successfully doing.

This is a world where something as simple as a missing "break;", or a ++X instead of a X++ can result in a very different output when you still have 99% of the same code, and unless you tell us exactly what your code is supposed to be doing and what the problem is it can be nigh impossible for us to find the problem without totally copying your code into a program and trying to recreate the entire project. Your explanation can be in your post, in comments in the code (which you probably should be doing more of anyways ), or both, but there's gotta be some explanation somewhere. I do enough attempting to wrap my head around nonfunctional code as a grader for one of my college's CS classes to know how hard it can be, and that's when I have a specific writeup detailing their problems and a specific list of the requirements.

So yeah, we'll gladly help you, but you gotta give us all the details you can or it rapidly becomes near impossible to debug. I'd rather have too much information about what you are trying to do than not enough, personally.