• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
Bow_vernon

Sweep test and physics

80 posts in this topic

Ok, Im worried about tunneling now, and I guess the best thing to do is a sweep test. now how to do it. with many objects there are many TOI. what do I do with them? and what is this "it may stuck, Bow!" my friend said on the phone? sadly he isnt able to explain more(on vacation). any suggestion?
0

Share this post


Link to post
Share on other sites
[quote name='Bow_vernon' timestamp='1299197193' post='4781589']
Ok, Im worried about tunneling now, and I guess the best thing to do is a sweep test. now how to do it. with many objects there are many TOI. what do I do with them? and what is this "it may stuck, Bow!" my friend said on the phone? sadly he isnt able to explain more(on vacation). any suggestion?
[/quote]

Ok, first let me say this: there is no way to avoid penetration in all cases. You *will* have to deal with it at some point, so all your collision detection/response routines will have to be able to detect and recover from it.

Secondly, dealing with lots of TOI events from multiple simultaneous collisions is *hard* and can be *very* slow. I faced this problem when writing the physics engine on little big planet psp...

The solution (and i can't take credit for it, unfortunately) is not to do it. Instead you need to use what i'm going to call 'predictive contacts'. These are detected by your usual time stepping collision detection code - there are several ways to do this, the most simple is to just use a closest points between objects routine.

These predictive contacts should do *no work* in the solver until the collision is due to happen, and when they do act, they don't remove all the relative normal velocity, they only remove exactly the right amount to bring the object to exactly touch the surface.

Thats the basic gist of it anyway, really this needs its own article and demo - if you'd like to see one please register your interest in this thread :)

Cheers, Paul.
0

Share this post


Link to post
Share on other sites
Eh? of course Im all interested. I know it's unvoidable, Im just trying to avoid tunnelling with a minimum of fuss. Im not used to CCD, what do I do with TOI? what should I add to the integration scheme (with the TOI)? Anyway, I dont need accurate TOI. Just a 'safe' value is enough. Thanks...
0

Share this post


Link to post
Share on other sites
[quote name='Bow_vernon' timestamp='1299235990' post='4781708']
Eh? of course Im all interested. I know it's unvoidable, Im just trying to avoid tunnelling with a minimum of fuss. Im not used to CCD, what do I do with TOI? what should I add to the integration scheme (with the TOI)? Anyway, I dont need accurate TOI. Just a 'safe' value is enough. Thanks...
[/quote]

I'm saying you might want to consider forgetting about TOI completely, use predictive contacts and let your contact solver do the hard work for you...

If you really must use TOI events then i would sit down on paper and draw out a bunch of different scenarios with several objects colliding in the next time-step each with different TOIs and note what happens when you solve each scenario in a certain order. Then switch the order around and try again - you'll notice it leads to a different outcome each time. The TOI events must be processed from earliest to latest...

If enough people chime in on this thread then i will consider writing the predictive contacts thing up formally with a demo :)

Cheers, Paul.


0

Share this post


Link to post
Share on other sites
Ok, Im very scared of tunnelling, ya know especially with small sized objects. I'll forget the TOI altogether, ok. Oh man if we wait for enough people in this thread, Im affraid it will take a long time...
I'll wait though, oops Im too happy and cant wait to see it >.<
0

Share this post


Link to post
Share on other sites
[quote name='Bow_vernon' timestamp='1299241764' post='4781723']
Ok, Im very scared of tunnelling, ya know especially with small sized objects. I'll forget the TOI altogether, ok. Oh man if we wait for enough people in this thread, Im affraid it will take a long time...
I'll wait though, oops Im too happy and cant wait to see it >.<
[/quote]

Maybe i can explain using a simple example :)

[list][*]Ok, take a small sized sphere object, travelling very quickly towards the ground.[*]Around the sphere, form a bounding box which encompasses the sphere on the current frame AND where the sphere will travel to on the next frame. Lets call this the swept bounding box.[*]If this swept bounding box intersects the ground on the current frame, there will possibly be a collision on the next frame.[*]So, we generate a predictive contact for the sphere and the ground. The simplest way to do this, is just to pick the closest points between the two objects as the collision points, and the normal is the unit length vector between these two points.[*]At contact solve time, the predictive contact will remove *only* the portion of the relative normal velocity that would cause the sphere to just touch the ground on the following frame.[/list]

Thats the gist of it - I've over simplified here for example purposes but that should get you started :)

Cheers, Paul.
0

Share this post


Link to post
Share on other sites
Im confused +.+a suppose I get the predictive CP, but at the current frame and the objects havent collided yet. Should I solve the predictive contact? that's weird. The objectsarent intersecting but we've solved CP. Or Im missing something??
*.*
0

Share this post


Link to post
Share on other sites
[quote name='Bow_vernon' timestamp='1299252318' post='4781762']
Me needs more explanation, puh lease +.+a
[/quote]

Because you know the objects will have collided somewhere between the current frame and next frame, its ok to solve the predictive contact on the current frame, because after you've solved it and the next frame rolls around, the objects will be just touching :)

Basically, you're throwing away some of the time involved in the collision by doing this, but in practice it looks totally unnoticeable :)

Cheers, Paul.
0

Share this post


Link to post
Share on other sites
Hey wildbunny,

I'm really interested in this topic. An article about it from you would be great!

Thanks in advance!
0

Share this post


Link to post
Share on other sites
Ok I'll try this, but theoritically there could exist a 'accumulated' energy gain, which could be a problem later. Anyway, why choose box as the swept shape? why not swept sphere? Since you mention 'take the sphere of the small shapes'
0

Share this post


Link to post
Share on other sites
[quote name='Bow_vernon' timestamp='1299256265' post='4781791']
Ok I'll try this, but theoritically there could exist a 'accumulated' energy gain, which could be a problem later. Anyway, why choose box as the swept shape? why not swept sphere? Since you mention 'take the sphere of the small shapes'
[/quote]

There isn't any noticeable energy gain - just play little big planet and you'll see :)

The swept bounding box is just for broad phase collision detection...

Cheers, Paul.
0

Share this post


Link to post
Share on other sites
for broad phase? you mean AABB? anyway like Mostem said, an article or source code or proof of concept would be great! Thanks in advance...right now Im working on how to generate contacts from two colliding OBB...
0

Share this post


Link to post
Share on other sites
[quote name='Bow_vernon' timestamp='1299257249' post='4781794']
for broad phase? you mean AABB? anyway like Mostem said, an article or source code or proof of concept would be great! Thanks in advance...right now Im working on how to generate contacts from two colliding OBB...
[/quote]

Yes, the AABB contains the sphere this frame and where it will be next frame - its bounded swept motion.

The contact points need to be on the sphere and the ground, not the AABB :)
0

Share this post


Link to post
Share on other sites
Ok, but ermmm sorry if I mind you, but...ehm can you give me a small 'demo' to proof the concept? teehee. I dont have the little big planet CD to install...I cant even download it...
0

Share this post


Link to post
Share on other sites
I created a proof of concept for predictive contacts in the Bullet SDK, thanks Paul for motivating me to do this. We discussed speculative contacts previously [url="http://code.google.com/p/bullet/issues/detail?id=355"]here[/url].

You can check out a Windows demo here:[url="http://code.google.com/p/bullet/downloads/detail?name=SpeculativeContactsWin32.zip"]http://code.google.com/p/bullet/downloads/detail?name=SpeculativeContactsWin32.zip[/url]
and see the minimal changes needed to enable them in this commit: [url="http://code.google.com/p/bullet/source/detail?r=2326"]http://code.google.c...e/detail?r=2326[/url]
The demo allows you to toggle between predictive contacts and conservative advancement using the P key. Shoot boxes using mouse button or . key.

In a nutshell, expand the bounding boxes with the motion, and for predictive contacts (with positive distance) adjust the constraint solver target velocity,
so that after integration the object will be in touching contact.

Cheers,
Erwin
1

Share this post


Link to post
Share on other sites
[color="#1C2837"][size="2"][color="#000000"][size="3"][quote name='DonDickieD'][/size][/color][/size][/color]
[color="#1C2837"][size="2"]How do you guys deal with restitution when using predictive contacts? [/size][/color]
[color="#1C2837"][size="2"][/quote][/size][/color]
Combining it with restitution requires some more work beyond my proof of concept implementation.

[quote name='DonDickieD' timestamp='1299297317' post='4781974']I also don't believe that predictive contacts avoid tunneling reliable. You can still easily rotate of the world.
[/quote]

I've seen several AAA games using predictive contacts to help preventing tunneling (sometimes combined with other techniques). There are several possible artifacts with predictive contacts, such as resolving contacts that didn't actually happen, but those game companies took those for granted. You can notice this effect in [url="http://code.google.com/p/bullet/downloads/detail?name=PredictiveContactsWin32.zip"][url="http://code.google.com/p/bullet/downloads/detail?name=SpeculativeContactsWin32.zip"]the demo[/url][/url] when shooting boxes with the right mouse button. DonDickieD's "rotate of the world" issue is a separate issue: predictive contacts bring the objects into touching contact. From there you can generate multiple contact points using your favorite method to avoid tunneling.


Let's stay on-topic: the links I provided show a sweep test using conservative advancement as well as a proof of concept of predictive contacts, as requested.
Here is the [url="http://code.google.com/p/bullet/source/browse/trunk/src/BulletDynamics/ConstraintSolver/btSequentialImpulseConstraintSolver.cpp?spec=svn2326&r=2326#558"]actual code[/url] to modify the right hand side of the contact setup to enable predictive contacts:
[code]

btScalar velocityError = restitution - rel_vel;
if (penetration>0)
{

// predictive contact: adjust the velocity error to allow to bring the objects into touching contact
// positive penetration values means separating/closest distance

positionalError = 0;
velocityError -= penetration / infoGlobal.m_timeStep;
} else
{
positionalError = -penetration * infoGlobal.m_erp/infoGlobal.m_timeStep;
}
[/code]
Thanks,
Erwin
0

Share this post


Link to post
Share on other sites
Erwin, I like to look at the demo and it doesn't run for me. Is this 64bit? Can you recompile it or add it to the Bullet trunk please.


Thanks,
-Dirk
0

Share this post


Link to post
Share on other sites
[quote name='DonDickieD' timestamp='1299342345' post='4782089']
Erwin, I like to look at the demo and it doesn't run for me. Is this 64bit? Can you recompile it or add it to the Bullet trunk please.


Thanks,
-Dirk
[/quote]

The demo and prototype speculative contacts are in trunk, see BasicDemo.


It was a 64bit executable indeed. I just replaced it with a Win32 binary here: [url="http://code.google.com/p/bullet/downloads/detail?name=SpeculativeContactsWin32.zip"]http://code.google.com/p/bullet/downloads/detail?name=SpeculativeContactsWin32.zip[/url]
Thanks,
Erwin
0

Share this post


Link to post
Share on other sites
I had a look at the demo and i just want to confirm something

purple boxes indicate moving objects, with dark blue indicating near by, scanned collision objects?
0

Share this post


Link to post
Share on other sites
[quote name='Bow_vernon' timestamp='1299472022' post='4782682']
Im still waiting for the paper/articles...
[/quote]

I will put it down on my list as the next thing to write about :)
0

Share this post


Link to post
Share on other sites
[quote name='DonDickieD' timestamp='1299296974' post='4781973']
How do you guys deal with restitution when using predictive contacts?
[/quote]

I've never worked on a game were restitution was required... But i don't *think* predictive contacts exclude the possibility of restitution - they are supposed to do no work until until they're 'required' to activate, although i can't remember the exact details of that last part right now... it worked along similar lines to a contact constraint using accumulated impulses...

Cheers, Paul.
0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0