Author Topic: Collision Problems  (Read 2655 times)

Offline KittenKoder

  • int
  • **
  • Posts: 66
  • I Am No One Else
    • View Profile
    • Kitt Games Wiki
Collision Problems
« on: December 01, 2012, 04:20:27 am »
Not sure if it's my code, or jPCT, as I still can't figure out exactly what's going on. But it only happens with scaled objects, almost as if the collision detection is scaled twice the object's scale. I'm using the ellipsoid detection, and the moving object is fine on objects scaled 1.0, it's any other scale value that has the effect. That's the best I can do to describe it. Any ideas?
When life throws you lemons, make lemon juice, then drop life into a pile of razors and pour the lemon juice over it.

Offline KittenKoder

  • int
  • **
  • Posts: 66
  • I Am No One Else
    • View Profile
    • Kitt Games Wiki
Re: Collision Problems
« Reply #1 on: December 01, 2012, 06:20:10 am »
After looking over some things, how is the collision ellipsoid used? Is it a number of world units or a multiplier of some sort? That could be my problem, I'm basing the ellipsoid on the size of the object, for the one that's moving, based off the bounding box, but now I think this may not be correct.
When life throws you lemons, make lemon juice, then drop life into a pile of razors and pour the lemon juice over it.

Offline EgonOlsen

  • Administrator
  • quad
  • *****
  • Posts: 11748
    • View Profile
    • http://www.jpct.net
Re: Collision Problems
« Reply #2 on: December 01, 2012, 08:20:06 am »
The ellipsoid is given in units in object space. If you an object, you have to scale the ellipsoid as well.

Offline KittenKoder

  • int
  • **
  • Posts: 66
  • I Am No One Else
    • View Profile
    • Kitt Games Wiki
Re: Collision Problems
« Reply #3 on: December 01, 2012, 08:42:37 am »
The ellipsoid is given in units in object space. If you an object, you have to scale the ellipsoid as well.

Ah, well the object that's using the ellipse isn't being scaled, oddly Blender units import to jPCT very well. So the bounding box should be usable for creating an ellipse, then scaling that as the object is? Or would it perform better to have the ellipsoid represent the aspects of the object?

Sadly this doesn't seem to help much with the strange problem I am having of the objects being collided with. The collision is still farther from the objects than the actual polygons.
When life throws you lemons, make lemon juice, then drop life into a pile of razors and pour the lemon juice over it.

Offline EgonOlsen

  • Administrator
  • quad
  • *****
  • Posts: 11748
    • View Profile
    • http://www.jpct.net
Re: Collision Problems
« Reply #4 on: December 01, 2012, 11:49:12 am »
Just fiddle around with the ellipsoid sizes. An ellipsoid as always an approximation of the object. If you make it so that it includes all polygons, it might be (depending on the object) too large for realistic collision behaviour. Also keep in mind (just in case you haven't) that the size of the ellipsoid is its radius, not its diameter.

Offline KittenKoder

  • int
  • **
  • Posts: 66
  • I Am No One Else
    • View Profile
    • Kitt Games Wiki
Re: Collision Problems
« Reply #5 on: December 01, 2012, 08:08:52 pm »
Just fiddle around with the ellipsoid sizes. An ellipsoid as always an approximation of the object. If you make it so that it includes all polygons, it might be (depending on the object) too large for realistic collision behaviour. Also keep in mind (just in case you haven't) that the size of the ellipsoid is its radius, not its diameter.

That's just it, after some testing, it's not the ellipsoid, it effects camera collision to. The solid, static, map object collision is really far from the actual polygons, it's noticeable when you scale them by an average of 8. Anything not scaled is not effected. So the ellipsoid of the moving object, based on what yo have stated here, is not the issue, and I can't figure out what is the issue. If I can't scale map object arbitrarily then I'm probably just going to have to get off my lazy but and write it all in raw OGL so I can.
When life throws you lemons, make lemon juice, then drop life into a pile of razors and pour the lemon juice over it.

Offline EgonOlsen

  • Administrator
  • quad
  • *****
  • Posts: 11748
    • View Profile
    • http://www.jpct.net
Re: Collision Problems
« Reply #6 on: December 01, 2012, 09:11:42 pm »
I'm a little confused about what writing stuff directly in OpenGL has to do with collision detection, but anyway... ;) I'm still not sure what exactly you mean. You scale the map, i.e. the objects you want to collide with and if you do that, the collision happens too early, i.e. when there shouldn't be any collision at all? Is that the problem? Do you have a test case for this?

Offline KittenKoder

  • int
  • **
  • Posts: 66
  • I Am No One Else
    • View Profile
    • Kitt Games Wiki
Re: Collision Problems
« Reply #7 on: December 01, 2012, 09:27:50 pm »
I'm a little confused about what writing stuff directly in OpenGL has to do with collision detection, but anyway... ;) I'm still not sure what exactly you mean. You scale the map, i.e. the objects you want to collide with and if you do that, the collision happens too early, i.e. when there shouldn't be any collision at all? Is that the problem? Do you have a test case for this?

It would be easier to start from scratch than to attempt to find a flaw that is possibly part of the library. I'm stressed because it all worked until this one point, which means I'd have to go back and rewrite some of the original code as well as develop loaders and all that.

The collision is happening too early, and I have everything at the lowest settings. It only happens when the objects on the map are scaled, as I said an average of 8 is when it's noticeable, I didn't notice it until I tested an area with objects that had to be scaled that much to avoid memory consumption, reusing the meshes. Just load a map with a bunch of objects and scale each object by at least 8 to 11, take another object you have the correct ellipsoid for, tested in environments without scaled objects, and you should see it. To better simulate what I am seeing you should have different scale values for the map objects, and shared meshes, though even objects without shared meshes still have the error. The case I have right now would be a huge upload/download, because it's part of the demo version of the game and depends on all the extra stuff to load properly.
When life throws you lemons, make lemon juice, then drop life into a pile of razors and pour the lemon juice over it.

Offline EgonOlsen

  • Administrator
  • quad
  • *****
  • Posts: 11748
    • View Profile
    • http://www.jpct.net
Re: Collision Problems
« Reply #8 on: December 01, 2012, 10:17:44 pm »
I'll look into it...

Offline EgonOlsen

  • Administrator
  • quad
  • *****
  • Posts: 11748
    • View Profile
    • http://www.jpct.net
Re: Collision Problems
« Reply #9 on: December 01, 2012, 11:15:40 pm »
Ok, please try this version: http://jpct.de/download/beta/jpct.jar

It should fix the problem (at least it did in my tests), but for high scaling values, you might now run into accuracy problems with floating point arithmetics. Try to avoid scales that are much higher then 10, if possible. Consider to use rescaled instances of your objects instead (maybe one for 1...10 and one for 10...20 or something like that).

Offline EgonOlsen

  • Administrator
  • quad
  • *****
  • Posts: 11748
    • View Profile
    • http://www.jpct.net
Re: Collision Problems
« Reply #10 on: December 01, 2012, 11:26:01 pm »
BTW: I still fail to see the relation between doing stuff in OpenGL and collision detection. One has nothing to do with the other. The means that jPCT offers to do collision detection can be used, but they don't have to be used. You could use any other other physics library out there, if you want to. jPCT's own ellipsoid collision detection is based on http://www.peroxide.dk/papers/collision/collision.pdf with some additions and fixes.

Offline KittenKoder

  • int
  • **
  • Posts: 66
  • I Am No One Else
    • View Profile
    • Kitt Games Wiki
Re: Collision Problems
« Reply #11 on: December 02, 2012, 01:00:40 am »
BTW: I still fail to see the relation between doing stuff in OpenGL and collision detection. One has nothing to do with the other. The means that jPCT offers to do collision detection can be used, but they don't have to be used. You could use any other other physics library out there, if you want to. jPCT's own ellipsoid collision detection is based on http://www.peroxide.dk/papers/collision/collision.pdf with some additions and fixes.

If I have to override the collision detection myself then I may as well write the whole thing from scratch because the only thing I'd be using from jPCT is the loader and OpenGL work. Also there are a lot of rendering capabilities I am not finding a way to access, though I don't remember how to do it off hand, I will have to look through old code again, there's a way to change the color of shadows on individual objects, as well as altering the specular color using OpenGL which would be a nice effect to have access to. Also there's non-uniform scaling, which offers a lot of useful manipulations.

I mean, jPCT is great, don't get me wrong, but some of the features I need just seem to be out of reach. If it was Open Source I'd go through your code and figure out ways to implement them without having to rewrite anything. Since every time I attempt to implement shaders the program locks up, and I'm almost clueless in that arena. I can't find a way to make it work the way I need to. But the collision is too important to overlook, I need that to work as expected, and I need it simple and integrated. Really, I'm just seeing my code use less and less of jPCT with each new development, and having to do a lot of it in my library, which also requires me searching for a method to override the jPCT portions. My library, and game, is just too involved to have to deal with headaches like this. I mean, seriously, the collision just went boom.
When life throws you lemons, make lemon juice, then drop life into a pile of razors and pour the lemon juice over it.

Offline EgonOlsen

  • Administrator
  • quad
  • *****
  • Posts: 11748
    • View Profile
    • http://www.jpct.net
Re: Collision Problems
« Reply #12 on: December 02, 2012, 09:15:45 am »
....but did the fix that i posted above work?

Offline KittenKoder

  • int
  • **
  • Posts: 66
  • I Am No One Else
    • View Profile
    • Kitt Games Wiki
Re: Collision Problems
« Reply #13 on: December 02, 2012, 10:29:32 pm »
....but did the fix that i posted above work?

Sorry, yes it did actually. Now it works perfectly.
When life throws you lemons, make lemon juice, then drop life into a pile of razors and pour the lemon juice over it.

Offline KittenKoder

  • int
  • **
  • Posts: 66
  • I Am No One Else
    • View Profile
    • Kitt Games Wiki
Re: Collision Problems
« Reply #14 on: December 02, 2012, 10:35:16 pm »
The problem with using multiple meshes is that it would seriously add drain to the GPU memory. Common buildings can have a size difference between 0.05 and 20 on the map, since the buildings are the main filler for the maps it would not be economical to create multiple meshes for each one, as I said, I just have to stop being lazy and figure out this GPU in OpenGL myself anyway. Though I may release the jPCT version first just to get it out there, I have to figure out how to budget new eyeglasses before I can continue testing anyway, not the glasses themselves but the exam, here in Seattle those are $70 or more, even at Walmart, and due to medical problems my budget only has a $50 leeway. But until I get new glasses I can't play 3D games at all, my prescription changed a lot in the last few years and I hadn't noticed since I normally hate 3D games. lol

Yeah, I'm an old skool gamer, but I have to adapt to the market if I want to get back into development.
When life throws you lemons, make lemon juice, then drop life into a pile of razors and pour the lemon juice over it.