• 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
Silverlan

PhysX - PxRigidDynamic clip through other actors (CCD enabled)

11 posts in this topic

This is a re-creation of my old thread here. I haven't been able to solve this issue and the thread got closed, so here's attempt 2:

 

My PxRigidDynamic actors intersect with other actors and I can't figure out why. There are still collisions between them, but the rigid dynamic slightly clips through them and is 'pushed' back. Here's a video of it ingame/in the PVD:

http://youtu.be/X0oyDtCTsuQ

 

The box is a PxRigidDynamic actor.

The player is a PxCapsuleController.

All other actors are PxRigidStatic.

 

Having CCD disabled or enabled seems to make no difference. (CCD should only affect high-velocity objects anyway, so I doubt that's the cause here)

 

The collisions between the controller and the static actors are fine, so I don't see why the rigid dynamic would behave any differently.

 

I'm using PhysX-3.3.0

0

Share this post


Link to post
Share on other sites

Are you calling PxRigidBodyExt::setMassAndUpdateInertia (possibly instead of setMass) after all the shapes have been created? That behaviour in your video is exactly what happens if this call is omitted.

1

Share this post


Link to post
Share on other sites

I was using 'updateMassAndInertia', just changed it to 'setMassAndUpdateInertia', but the result is the same.

I didn't use this function on my character controllers and static actors (Like the world), but I assume that's not neccessary?

0

Share this post


Link to post
Share on other sites
Yes, it should be called on dynamic actors only. Otherwise static/dynamic actor initialization should look quite similar. I assume you're not manually applying impulses on the box (at onShapeHit callback)? Does your box behave like that if you're not pushing it with the character controller? Does it penetrate the static actor if it falls? I still suspect there's something wrong with how you're creating your dynamic actors. Even if the cc pushed the box in to the wall/ground, it should jump right off. Post some initialization code maybe so that can be ruled out?
1

Share this post


Link to post
Share on other sites
I'm applying my own gravity, but that's just 'addForce' with the 'physx::PxForceMode::eACCELERATION' flag.
And yes, the box behaves like that even if it is just interacting with the world (static actor):
http://youtu.be/GBCw4-MPOUw
 
As for the initialization, it's mainly this:
 
Line 53 is where the actual actor is created.
0

Share this post


Link to post
Share on other sites

Okay, I didn't notice anything odd in the code. But by looking that video I noticed that your world scale is enormous compared to that grid (it's not possible to scale that grid, is it?). What units are you using? It's known that too small units can cause jittering when using inappropriate contact offsets. There's something in the documentation about this and here: http://www.nvidia.com/object/physx_knowledge_base.html (it's for the previous version but probably still valid).

Edited by fanwars
1

Share this post


Link to post
Share on other sites

Make sure the PxTolerancesScale values are sensible when you create your scene - as fanwars suggests.

 

Make sure your iteration counts are OK - e.g. 4 for position iterations is sensible, and 2 for velocity (penetration correction). Though what you're seeing is so bad that I don't think it's this.

 

Also make sure that the shape contactOffset and restOffset are sensible for your units, on all shapes, static and dynamic (but again, I don't think it's this).

 

If you can upload a short PVD capture I'll take a look...

1

Share this post


Link to post
Share on other sites

Well, I'm currently using the same world scale as the source engine does, which means that 1 unit equals 19.05mm.

I'd hate having to change the scale of everything in my world, but I'd also like to avoid having a different scale for the physics only. Any way to compensate? If that's actually the issue here.

 

Here's a PVD capture, hope it'll give a bit more insight:

http://filesmelt.com/dl/physx_test1.zip

0

Share this post


Link to post
Share on other sites

OK great - having looked for just a few minutes:

 

1. The way the box falls, it doesn't look like CCD is enabled - are you sure it's enabled in the filter shader as well as the scene and dynamic actor (I can see the flag is these two)? However, this is not the cause of the problem. 

 

2. Your box looks like it's about 50 units across. The contactOffset value is 0.02 which is tiny, in proportion. I'd suggest setting contactOffset to 1. But I don't think this will solve the problem. 

 

3. The scene is reporting gravity as (0,0,0) (and the object has eDISABLE_GRAVITY) - is that right? So you're applying gravity manually? I don't see why you shouldn't - a constant force shouldn't cause penetration problems... but maybe it is.

 

4. PVD doesn't report the tolerancesScale length/mass values - but it does say the "normal" speed is 10 units/s. When your box falls it his the ground at about 909 units/s

 

I would:

 

1. Disable CCD for the moment - it hasn't been reliable in the past (though is probably fine now)

 

2. Make sure the PxTolerancesScale is set correctly

 

3. If that doesn't work, see whether it's due to disabling gravity and applying the gravitational force manually (if this is it, it sounds like a PhysX bug).

1

Share this post


Link to post
Share on other sites

1) The physx::PxSceneFlag::eENABLE_CCD is set in the PxSceneDesc and physx::PxPairFlag::eCCD_LINEAR inside the CCD Filter Shader.

The actor's also have the 'physx::PxRigidBodyFlag::Enum::eENABLE_CCD' and the 'physx::PxRigidBodyFlag::Enum::eENABLE_CCD_FRICTION' flags set.

2) How do I change the contact offset for dynamic actors? 'setContactReportThreshold'?

3) Yes, as I've said, I'm applying my own gravity. I disabled it and tried it with physx' inbuilt gravity as you've suggested, but the result was the same. (Without the below changes)

4) I've changed the values to the following:

length:

From the documentation: "For simulating roughly human-sized in metric units, 1 is a good choice. If simulation is done in centimetres, use 100 instead. This is used to estimate certain length-related tolerances."

Since in my case 1 unit = 19.05mm, I chose 190.5 as an appropriate value.

mass:

"The approximate mass of a length * length * length block. If using metric scale for character sized objects and measuring mass in kilogrammes, 1000 is a good choice."

My measurement is in kilogrammes, so I've set it to 1000.

speed:

"For normal physical environments, a good choice is the approximate speed of an object falling under gravity for one second."

This one's a bit difficult to determine in my case. The gravity can change entirely and there is no 'typical' velocity. I've set it to 180 for now.

 

That seemed to do the trick, although I can't push the box anymore, even with a low mass:

http://filesmelt.com/dl/physx_test2.zip

 

How can I change the push force of a controller?

Also, if you check the capture, you'll notice there's a rather large offset around the controller to anything it touches:

7iCsy.png

 

I've set the contact offset in the PxCapsuleControllerDesc to 0.01.

Why is the offset still that large?

 

Thanks to both of you, I'm already a large step further!

Edited by Silverlan
0

Share this post


Link to post
Share on other sites

If I'm not mistaken, the character controller shouldn't automatically push objects around it (see documentation). Normally you would apply the pushing forces manually. There's onShapeHit -callback for this purpose. This way you have more control over the forces anyway. The character controller pushing objects in your previous build might have been a side effect caused by invalid scene configuration.

 

I don't know about the offset though, so I can't really help with that... Have you tried fixing that offset between ground and bottom with setFootPosition ?(e: nevermind, I don't think this is related to the actual issue).

Edited by fanwars
1

Share this post


Link to post
Share on other sites

Thank you, most of my problems are solved now. Still don't have a clue what's causing the collision offset though, if anyone can shed some light on that it would be very much appreciated.

 

I'm also having another related problem.

I want to check whether the character can uncrouch, or if there's an obstacle preventing it.

The problem is, it reports an overlap even if the controller is just on the ground, but nothing above it. Here's an extract of the overlap-check:

physx::PxScene *scene = controller->getScene();

physx::PxReal r = controller->getRadius();
physx::PxCapsuleGeometry geom(r,m_standHeight *0.5f);

physx::PxExtendedVec3 posExt = controller->getFootPosition();
posExt.y += m_standHeight *0.5f;
physx::PxVec3 pos(posExt.x,posExt.y,posExt.z);
physx::PxOverlapBuffer hit;
PhysXPlayerControllerFilterCallback filterCall(controller->getActor());
if(scene->overlap(
		geom,
		physx::PxTransform(pos,controller->getActor()->getGlobalPose().q),
		hit,
		physx::PxQueryFilterData(physx::PxQueryFlag::eANY_HIT | physx::PxQueryFlag::eSTATIC | physx::PxQueryFlag::eDYNAMIC | physx::PxQueryFlag::ePREFILTER),
		&filterCall
	) && hit.hasBlock)
	return false;

PhysXPlayerControllerFilterCallback returns physx::PxQueryHitType::Enum::eTOUCH for anything that isn't the controller's actor.

I've tried adding a minor offset upwards of several units to the position, but that didn't help.

 

Is there a way to visualize the overlap in the PVD?

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