Determining when and where collisions have occurred?

iPi · 01-12-2009 03:13 PM

Hi,

Just started to use your engine, love it so far, but I'm a little confused about how to find out when any collisions have occurred.
And in case it is not a part of the returned data, is there any other way of determining the force of the impact?
My idea is that if the player trips over something, I want to engage the ragdoll so he can trip and fall properly, in case you can suggest a better method?

Oh lastly, to the author, any idea when you'll be adding rain?

**Esenthel** · 01-12-2009 10:07 PM

Hi, thanks for your comment, I appreciate it smile

Could you point me to a video (it would be best) or images, what exactly you'd like to achieve? how the character would react.

Lately there has been discussed detecting damage for a falling character from a height, I don't know if it may help you but the idea was to record player velocities while he was in air, and later when he suddenly hit the ground (Character.ctrl.onGround()==true) you could evaluate the last known player velocity while in air, and on the base of its length calculate the damage.

If it's not exactly what you had in mind, images or video, or more detailed explanation would be welcome smile

About the rain, thanks I'll think about it, right now I have a huge list of things to do in the engine, for the moment don't know which will be the next one developed.

iPi · 01-12-2009 10:44 PM

Likewise, thank you for the engine, I REALLY appreciate it smile

best one i've come across yet. and i've tried em all. smile

As for falling damage, that is important, but not what i had in mind.

I don't have any videos, as i havn't seen any other game do it yet.
Best way to describe it is, imagine the player getting shot as he is running, i want to switch to ragdoll mid run, but not when shot, when a 'hard' collision has occured.

Most such collisions when running don't affect velocity much. I suppose I could check for sudden up shift, but I'm not really a fan of kludges when a better alternative exists.
Which in this case, is grabbing collision data from phys and determining which characters and items they belong to.
I realize this isn't possible if the engine doesn't already expose the nessacary methods, so if it doesn't, please consider this post a feature request smile

Cheers.

iPi · 01-12-2009 10:48 PM

Btw sorry if i wasn't clear, but i do know how to do the ragdoll part, it's just finding out when to do it is the problem.

Basically, i would love it if i could do something like this,

void Player::OnCollision(Vec pos,Vec norm,Obj a,Obj b,Vec Force)
{
}

a simple method i can just overide and then deal with each collision as needed.

But any way of doing it would be ok really, i'm not fussy smile

**Esenthel** · 01-14-2009 04:48 PM

detecting if a player is shot is done manually, depending on your shooting functions

typically when shooting a bullet you should check if it collides with a big Ball around a characters, if it is, then you should perform a more detailed check around characters Skeleton Bones.

iPi · 01-15-2009 01:41 PM

yeah that's the approach i prefer. first thing i check with a new engine besides what fx it is, if it has a solid linepick function smile

yours does so that's not a concern. I alreayd use it for camera<>scene avoidence.

But what I need to know is, how to determine when a character has collided with the terrain and static geo. Like buildings/ logs/tables.

Least of all, for sound fx. most of all for physics responses beyond the kinetic ones. Like tripping.

If it's not possible yet, it's no problem. I see you update quite reguarly. I love that. Everyday's a new adventure "New version! Oh yes!" smile

**Esenthel** · 01-16-2009 01:12 PM

I understand, I'll add this functionality on my list (its getting bigger and bigger)

Quote:I see you update quite reguarly

yep, working on the engine all the time, however the past few days I was totally ill (huge fever) so the works were paused, but now feeling better, and can get back to work smile

iPi · 01-16-2009 04:26 PM

I was going to say, it's been a while since your last update. pfft

Thanks for adding it to the list. One other major problem i'm having, well i say other, the only other problem i'm having, is the lack of exploination between screen and gui coordinate systems. and also, which api custom widgets should use to draw their content.
Reason being, I've wrote a custom struct extending the base gui widget(Not GCustom, I simply reference it's size and position from the gui editor produced contents) that will display a 2d map of the local area, and it's been quite confusing knowing what values to use to actually do things i normally do in pixel space.

so long question, well, excedingly long, is there any possibly of a switch to turn all 2d operations into normal pixel space.

or perhaps more realistically, a simple function that converts from one space to another.

The other problem was, i wasn't sure how to handle rendering the children of widgets. I assume the GuiPC * value automatically takes into account parent offsets etc, but it would be nice to know for sure.

In fact, if it interests you at all, in a effort to learn all I need to realize my game, and help you, how about we do a little faq or doc covering all these basic needs?

I assume you'd rather do it yourself, and that's of course fine, but if you could add it to very long list.

The only question is, what is longer, your list or this post. Don't tell me. I do not want to know.

smile

**Esenthel** · 01-16-2009 04:46 PM

Hi,

there are functions for converting spaces screen<->pixel (check out D - Display header file

Code:

// convert coordinates                                                 src.X          src.Y                         dest.X         dest.Y

   static Vec2  screenToUV       (Vec2  &screen); // from screen      (-D.w .. D.w  , -D.h .. D.h  ) to UV          (   0 .. 1    ,    0 .. 1    )

   static VecI2 screenToPixel    (Vec2  &screen); // from screen      (-D.w .. D.w  , -D.h .. D.h  ) to pixel       (   0 .. D.x  ,    0 .. D.y  )

   static RectI screenToPixel    (Rect  &screen); // from screen      (-D.w .. D.w  , -D.h .. D.h  ) to pixel       (   0 .. D.x  ,    0 .. D.y  )

   static VecI2 screenToPixelSize(Vec2  &screen); // from screen size (   0 .. D.w*2,    0 .. D.h*2) to pixel  size (   0 .. D.x  ,    0 .. D.y  ), use this function for widths and heights

   static Vec2  UVToScreen       (Vec2  &uv    ); // from UV          (   0 .. 1    ,    0 .. 1    ) to screen      (-D.w .. D.w  , -D.h .. D.h  )

   static Vec2  pixelToScreen    (VecI2 &pixel ); // from pixel       (   0 .. D.x  ,    0 .. D.y  ) to screen      (-D.w .. D.w  , -D.h .. D.h  )

   static Rect  pixelToScreen    (RectI &pixel ); // from pixel       (   0 .. D.x  ,    0 .. D.y  ) to screen      (-D.w .. D.w  , -D.h .. D.h  )

   static Vec2  pixelToScreenSize(VecI2 &pixel ); // from pixel  size (   0 .. D.x  ,    0 .. D.y  ) to screen size (   0 .. D.w*2,    0 .. D.h*2), use this function for widths and heights

however, I disencourage working in pixel space, because your coordinates will not work when setting a differet screen resolution mode

screen coordinates are the same as GUI coordinates,
Y ranges from -D.h() .. D.h() (this normally is -1 .. 1 )
and X ranges from -D.w() .. D.w()

yes, GuiPC handles parent offsets and other

if you want to make a custom gui element please give a little more details about it, so ill make some more tutorials about it and make it easier
however simple things can always be done using manual drawing (Gfx::draw, D.line, D.text and stuff..)

I'd like my list to be just as long as your post smile

It's at least several times bigger

iPi · 01-18-2009 01:40 PM

Heh, I know the feeling. Atm, I'm working on a ps3 raytracer, a gl engine, and my game using your engine.

and that's me trying to forget i have a 99% finished C# 3d engine to release.

here is how i deal with it: I don't. Just ignore it. it will take care of it's self. everything will be alright if you hide underneath the coats smile

Try it, might work for you as well as it has me smile

---

Sorry back on topic, yeah, I can understand why using a constant range like -1 to 1 can be better for different resolutions. That's just not something I've ever worried about too much, as I havn't released many games. just engines and so fourth.
But I guess you're right, so consider the request dropped. I will learn to live with your(better) method smile

Thanks for the help.

Determining when and where collisions have occurred?
Author	Message