> Correct me if I'm wrong, but don't game engines "usually" use an invisible 
> skeleton rather than the actual visible polygon mesh for collision 
> detection purposes? (Precisely to simplify the problem and make it 
> tractable in realtime.)

No, you're completely correct, in fact I'm already doing that in my game. 
The problem I have now is that because my physics loop runs at 100 Hz and 
some objects are moving quite quickly (like a metre per physics step) it's 
hard to determine exactly where the collision took place, and hence 
calculate the correct impulse to stop them intersecting at the next step.  I 
don't have enough CPU cycles spare to roll back the simulation with a finer 
time step, so I'm just using some hackery to estimate it for now.  It works 
ok most of the time, and things bounce and spin off nicely in 3D, but 
occasionally one object visibly goes inside another for a bit.  I'm sure 
with a bit more hackery I can make it more robust without having to do more 
physics steps.  Then I need to optimise the collision *detection*, as it 
gets a bit slow when 10 or so objects are colliding simultaneously.

Post a reply to this message

>> Correct me if I'm wrong, but don't game engines "usually" use an 
>> invisible skeleton rather than the actual visible polygon mesh for 
>> collision detection purposes? (Precisely to simplify the problem and 
>> make it tractable in realtime.)
> 
> No, you're completely correct, in fact I'm already doing that in my 
> game.

Yay for me!

> The problem I have now is that because my physics loop runs at 100 
> Hz and some objects are moving quite quickly (like a metre per physics 
> step) it's hard to determine exactly where the collision took place, and 
> hence calculate the correct impulse to stop them intersecting at the 
> next step.  I don't have enough CPU cycles spare to roll back the 
> simulation with a finer time step, so I'm just using some hackery to 
> estimate it for now.

I was under the impression that this is pretty much standard procedure; 
compute the path of an object for the next few split seconds and see if 
it intersects the path of anything else. Otherwise objects would have to 
collide exactly on the bounderies of your time steps - which is, uh, 
"improbable". ;-)

> It works ok most of the time, and things bounce 
> and spin off nicely in 3D, but occasionally one object visibly goes 
> inside another for a bit.

That's nothing! With the Havok physics engine, sometimes objects hit the 
ground and flail around indefinitely. (Presumably the engine trying to 
prevent the object intersecting the ground.) Sometimes objects just keep 
jiggling and won't stop - and sometimes the movement is quite significant.

> I'm sure with a bit more hackery I can make 
> it more robust without having to do more physics steps.  Then I need to 
> optimise the collision *detection*, as it gets a bit slow when 10 or so 
> objects are colliding simultaneously.

Uh, yeah, I have no idea how to fix that...

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Invisible wrote:
> So I gather we have some of these in here somewhere?

I dabble. I've worked out the timing issues, which is a big step, but I 
still haven't released a full-featured game because DirectX looks 
different depending on the hardware used to view it.

> If there's this many people wanting to get in, it must be pretty 
> competetive. 

It's bad enough wanting to do graphics for a living. There are plenty of 
people clamoring for what few jobs there are... Fortunately, many of 
those loud people aren't very good at their jobs ;)

About games programming. If you really want to do something, do it alone 
and in your spare time. Come up with something special, and you might 
become another success story like the developers of Cave Story, Crayon 
Physics, Fez... some of these guys have won large cash prizes for simply 
being good at what they do in their spare time. Companies are contacting 
*them*, not the other way around.

BTW, Fez looks like a game I might actually buy. Cool-looking stuff...

Sam

Post a reply to this message

> I was under the impression that this is pretty much standard procedure; 
> compute the path of an object for the next few split seconds and see if it 
> intersects the path of anything else.

Well yes, but I can't do the full simulation any more often because it's 
already too slow (simulating car tyres accurately and suspension for several 
cars is not fast!).  What I think I could do is to wait until a normal 
physics step indicates two objects are colliding (it is unlikely they would 
completely miss each other, unless travelling very fast or only just 
"scraping" a corner at speed, both of which I think I can ignore for now). 
Then, assume constant velocity and work backwards until the two objects are 
*just* touching.  Do the same for any other collisions, then find the 
earliest collision in time, apply the repelling impulses and do a full 
physics step from that time onwards.  Then repeat the above until no more 
collisions are found in that time period.  Hopefully that will not require 
too many more physics steps and should avoid things going wrong with fast 
objects.

> Otherwise objects would have to collide exactly on the bounderies of your 
> time steps - which is, uh, "improbable". ;-)

Well currently I just detect if they are intersecting and moving towards 
each other, and if they are apply an impulse to each object to separate 
them.

> That's nothing! With the Havok physics engine, sometimes objects hit the 
> ground and flail around indefinitely. (Presumably the engine trying to 
> prevent the object intersecting the ground.) Sometimes objects just keep 
> jiggling and won't stop - and sometimes the movement is quite significant.

Yep!

>> I'm sure with a bit more hackery I can make it more robust without having 
>> to do more physics steps.  Then I need to optimise the collision 
>> *detection*, as it gets a bit slow when 10 or so objects are colliding 
>> simultaneously.
>
> Uh, yeah, I have no idea how to fix that...

Need to implement some sort of LOD / binary tree of the collision mesh, at 
the moment I just test every face of the mesh against every other face once 
the objects' bounding spheres are intersecting.

Post a reply to this message

Warp wrote:
> Invisible <voi### [at] devnull> wrote:
>> I'm still fairly sure I don't have what it takes, but casual gaming 
>> isn't something I'd considered. Maybe it's not as impossible as I'd 
>> imagined. Hmm... something to think about anyway.
> 
>   Be careful, though: If you go into casual gaming, there's a high
> probability that you will have to develop games for the iPhone, which
> is probably against your deepest principles. ;)
> 

Or Flash. And a bit of Flash development goes on on Macs.


I keep hoping to get used to the difference. One would think that Adobe 
would make a smooth transition between the two platforms, but no. Alt+F9 
is now apple+F9, but CTRL+F8 maps to Alt+T or something like that. I 
forget the actual keys that are mixed up, Adobe has trained me to slow 
down and go back to the mouse.

Post a reply to this message

"Orchid XP v8" <voi### [at] devnull> wrote in message 
news:48c6cc58$1@news.povray.org...


>> It works ok most of the time, and things bounce and spin off nicely in 
>> 3D, but occasionally one object visibly goes inside another for a bit.
>
> That's nothing! With the Havok physics engine, sometimes objects hit the 
> ground and flail around indefinitely. (Presumably the engine trying to 
> prevent the object intersecting the ground.) Sometimes objects just keep 
> jiggling and won't stop - and sometimes the movement is quite significant.

    Yeah, that's quite standard in games at the moment from what I've 
experienced. In Crysis, I've thrown a grenade at an NK, killed him, and he's 
been catapulted through a building wall - only to be stuck in that portion 
of the wall. Very funny to watch. :)

 See this vid: http://www.youtube.com/watch?v=6vK3CfiYCao

  Is this down to programming?


    ~Steve~



>
> -- 
> http://blog.orphi.me.uk/
> http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

> (As some of you may remember, the careers advice guy said I should 
> consider games programming. Personally I think it's a pretty absurd idea. 
> If there's this many people wanting to get in, it must be pretty 
> competetive. And presumably being hyper-fluent in C and/or C++ is an 
> absolute mandatory requirement. Both of these things pretty much instantly 
> rule me out completely...)

If you can learn an obscure language like Haskell, you can learn C++. If you 
learned C++, or maybe Java if you preferred, you could use that skill to get 
a job you would like (games or not). Why don't you put the time into it? I 
had a lot of fun with C++ and OpenGL in college. It's really not that hard 
to learn for someone like you.

 - Slime
 [ http://www.slimeland.com/ ]

Post a reply to this message

And lo on Tue, 09 Sep 2008 19:48:55 +0100, Warp <war### [at] tagpovrayorg> did  
spake, saying:

> scott <sco### [at] laptopcom> wrote:
>> Do you fancy trying to write a fast, realistic looking, and robust  
>> collision
>> engine for meshes in 3D?
>
>   Why reinvent the wheel, when there are lots of such libraries already
> available and widely used in games?

Because you might end up with a better wheel or even a hover-bike :-)

-- 
Phil Cook

--
I once tried to be apathetic, but I just couldn't be bothered
http://flipc.blogspot.com

Post a reply to this message

Slime <fak### [at] emailaddress> wrote:
> If you can learn an obscure language like Haskell, you can learn C++. If you 
> learned C++, or maybe Java if you preferred, you could use that skill to get 
> a job you would like (games or not). Why don't you put the time into it? I 
> had a lot of fun with C++ and OpenGL in college. It's really not that hard 
> to learn for someone like you.

  The big problem with someone who has programmed almost exclusively with
a language like Haskell for the past years is that he will be very biased
towards the features and strong points of that language, and will then be
constantly pulling his hair when trying to code something in C++. "Why do
I have to do it like this? It's stupid. Why can't I do it like in Haskell?"

-- 
                                                          - Warp

Post a reply to this message

stbenge wrote:
> BTW, Fez looks like a game I might actually buy. Cool-looking stuff...

I had not heard of Fez before, but I agree that it does look like it has 
some pretty good potential.  It looks sort of like like a super-fancy 
Cave Story, so hopefully the actual gameplay will be of as high a 
quality as well.  Thanks for alerting me its existence!

Post a reply to this message