Jump to content

  • Log In with Google      Sign In   
  • Create Account

We're offering banner ads on our site from just $5!

1. Details HERE. 2. GDNet+ Subscriptions HERE. 3. Ad upload HERE.


Yours3!f

Member Since 04 Feb 2011
Offline Last Active Yesterday, 05:33 AM

Posts I've Made

In Topic: want to create an fps

15 November 2014 - 01:07 PM

Well then just fix the bounding boxes, because the idea is that inside the bounding box it's a solid object, if you want to model something hollow - do it with a few bounding boxes - it's the easiest way, and will save you some headaches.

Allright, fixed it. And by that I mean that I wrote some code to ignore AABBs that enclose the player at start, plus I had to add some dummy geometry in blender so that there are replacement AABBs.

I also had to modify that collision code a bit...
 

//if b collides w/ a, we set b's position, so that it's outside a
//an aabb is defined by it's position (center), it's half-extents, and min/max vertices
void collide_aabb_aabb( aabb a, aabb& b )
{
  if( a.intersects( &b ) && //there's an intersection, need collision response
      !b.is_inside( &a ) ) //but only if we're not inside
  {
    vec3 diff = b.pos - a.pos;
    vec3 abs_diff = abs( diff );
    vec3 extent_diff = (a.extents + b.extents) - abs_diff;

    vec3 res = vec3( 0 );

    //min search
    int idx = 0;
    for( int c = 1; c < 3; ++c )
    {
      if( extent_diff[idx] > extent_diff[c] )
        idx = c;
    }

    //final "collision response"
    res[idx] = extent_diff[idx] * sign(diff[idx]);

    b = aabb( b.pos + res, b.extents );
  }
}

Next questions :)
So now I want to add enemies, I can already do gpu skinning, however I suppose that in order to be able to shoot certain body parts, I need to move the collision geometry with the parts. So I suppose I need to modify them using the same bones that a mesh has. Is that right? And how do I figure out which bones should affect for example the head's sphere?

 

Also how can I blend between animations for for example the weapon animations? (idle/reload etc.)


In Topic: want to create an fps

15 November 2014 - 07:57 AM

Solving analytically the collisions is more accurate and sidesteps a number of issues. Heck even engines from 2007 use it(http://www.blitzbasic.com/ - b3d went open source - you can check the collision code). Another thing is that you can deal with collisions of multiple moving bodies correctly if you implement the analytical solution. What the solution does is basically mathematically "predict" exactly where the collision occurs. So even if you deal with many moving objects you can still get a correct resolution of the collisions. On the other hand the "check if you're inside the object then resolve the collision" type of methods usually have the issue that you can pass through the object if you translate with a vector with a big enough magnitude (imagine having lag and needing to sync after that - you'll need to make bigger translations to make up - which will result in a disaster). Another thing is that you cannot say which collision happened first and which second,third etc. during this frame - so you'll have an issue if you're looking for even a bit of complexity in the collision handling. And I shouldn't mention that if you evaluate a collision between 2 or more moving objects the method you use works even worse. The method I showed you is harder, but I believe that the extra effort is worth it, as you'll avoid quite a few issues, while the collision system would be more flexible and easily extensible (+ it's easier to resolve collisions when you know exactly in what order and at what coordinates objects will collide - then you can go for various resolution models). 

On a side note - it's not a good idea to have your object in the bounding box of another - the idea is that objects are solid even if in computer graphics you just draw the surface - so you'd better do the extra effort of making a bounding box for each of the sides if the object is supposed to be hollow - that would save you some real effort later on imo(I shouldn't even mention that usually the back polygons will be culled - so even your geometry would be changed if you want to model a hollow object).

 

P.S. Mind you in the 0) - 4) steps you need to mark your objects as collided if they collide so they don't get stuck to the other object before even having the chance to resolve the collision(lest you want response stop - but still it's good to have a collided flag). You can have various code implementations, but the basic idea is simple - check all the collisions that could occur (and btw I'd advise another collision routine for moving vs static objects, because moving to moving is harder as you see) - find the one that will occur after the least period of time - then update every moving object with this time period -> repeat (somewhere along the way in the next cycle of this algorithm you need to resolve the actually collided objects - not the predicted ones). It could be optimized if you butcher up accuracy. 

 

P.P.S. Check this http://www.stencyl.com/help/view/continuous-collision-detection/

 

I know about these issues, I read the blog posts on http://www.wildbunny.co.uk

However the gameplay would be so simple that I don't want to do a complete collision system just one that's "good enough" that's why I didn't bother with all these things...

I decided that the dynamic objects can't collide with each other, and they will not move that fast that I'd need analytic collision handling (for bullets I'll use simple rays, not moving spheres).

 

You're right though, a proper system would involve these things. However I think I'll switch to Bullet as soon as things would get messy, as I really don't want to reinvent the wheel. It's just that for a game this simple, I think this should do fine.

 

I'll update the sponza scene so that there won't be big AABBs.


In Topic: want to create an fps

15 November 2014 - 06:03 AM

@lightxbulb

 

thank you! I think I do understand the intersection math, and the basic physics stuff. What I think I don't understand is the practical considerations...


In Topic: want to create an fps

15 November 2014 - 05:51 AM

so after some reading in the subject I decided to go with a rather simple strategy (I realized I definitely don't want to write a physics engine...):

Collisions should only make sure that the player (and the enemies) can't go into walls, and can't leave the map. So I created a rather simple collision mechanism, everything is represented by AABBs, and I try to keep the dynamic (player+enemies) AABBs out of the static ones.

 

here's the code I wrote for this purpose:

//if b collides w/ a, we set b's position, so that it's outside a
//an aabb is defined by it's position (center), it's half-extents, and min/max vertices
void collide_aabb_aabb( aabb a, aabb& b )
{
  if( a.intersects( &b ) && //there's an intersection, need collision response
      !b.is_inside( &a ) ) //but only if we're not inside
  {
    vec3 diff = b.pos - a.pos;
    vec3 abs_diff = abs( diff );

    vec3 res = vec3( 0 );

    //max search
    int idx = 0;
    for( int c = 1; c < 3; ++c )
    {
      if( abs_diff[idx] < abs_diff[c] )
        idx = c;
    }

    //final "collision response"
    res[idx] = ((a.extents[idx] + b.extents[idx]) - abs_diff[idx]) * sign(diff[idx]);

    b = aabb( b.pos + res, b.extents );
  }
}

However when I tried it on the Sponza test map, I'm facing the problem that for AABBs that completely enclose the player's AABB once I get outside of them, I can't get back inside, so this way there are some problematic AABBs (bigger meshes...). Also if I don't check if I'm inside the other AABB or not, I just get pushed outside immediately...

Obviously I could alleviate the problem by using 4 walls instead of a box, but then I should ignore some AABBs, rigtht? But is there a better solution to this?

 

here's a demo to show what I mean:

https://drive.google.com/file/d/0B33Sh832pOdOYlN6b0cyZjRDcGs/view?usp=sharing


In Topic: want to create an fps

10 November 2014 - 04:33 PM

That's a decent example of your goal. To apply my suggestions to CS -

 

The world could be comprised of simple triangle meshes (graphics) and OBB/AABB** collision objects. The character collision object may be one or more spheres, but may also be just an OBB. The skinned mesh character animations seem to be few (run, walk, throw grenade, fire, etc.). The first person animations seem to be a bit more elaborate but may just be subsets of the skinned mesh animations. You could get away with a collision engine with a simple OBB/OBB collision routine, and maybe a ray/OBB for bullets.

 

** rectangular walls (AABB or OBB) and sloping (no curve) surfaces (OBB).

 

The HalfLife/TF/CS engine pretty much forces you to have a contained world. For your purposes, you may want to bound each level of your app with a box, perhaps comprised of 6 (infinite) planes. Object-plane collision is very fast. Just to keep your characters from dropping out of the world.

allright, thanks! I'll try to do this, and will post again, if I get stuck/have a question!


PARTNERS