|
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> 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 I enjoy coding and learning from it. I'm writing this for fun, not
in order to make the maximum profit with the least work from my side!
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.
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
|
|
| |
| |
|
|
|
|
| |
|
|