Jump to content

  • Log In with Google      Sign In   
  • Create Account

MrRowl

Member Since 01 Jan 2004
Offline Last Active Yesterday, 02:20 PM

#5177686 Fixed-Time step only for physics ?

Posted by MrRowl on 02 September 2014 - 11:21 AM

If you have to ask, and want a rule that just works without having to think too hard, then use a fixed timestep.

 

if you understand the underlying system, can figure out what problems and benefits you might get, then a variable timestep might be better. it will depend on the game and platform. 

 

I use a variable step so that I always have an integer number of physics steps per render update - but that integer is adjusted to keep the physics step itself reasonable. I have no need for determinism, am confident that my simulation is well behaved for the range of timesteps that can occur, and as a result don't need to interpolate between physics frames (which can simplify debug output too). This is for my PicaSim flight simulator.




#5136273 PhysX - PxRigidDynamic clip through other actors (CCD enabled)

Posted by MrRowl on 04 March 2014 - 03:52 AM

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).




#5136200 PhysX - PxRigidDynamic clip through other actors (CCD enabled)

Posted by MrRowl on 03 March 2014 - 04:30 PM

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...




#5094681 Advanced Character Controller based on PhysX 3.2.4

Posted by MrRowl on 17 September 2013 - 09:53 AM

I haven't had a chance to download your code or study the video in detail (though with a brief look it seems good!), so please excuse me if I missed something you've already done/described, but here are a couple of features that aren't mentioned in your list, and are quite important:

 

1. Ability to push dynamic objects (optional)

2. Ability to be pushed by dynamic objects (optional)

3. Ability to step over small objects...

4. Without being able to climb really steep slopes (I'm not sure how it is at the moment, but I've certainly seen problems with vanilla PhysX CC where if you enable stepping the the slope limiting is badly broken)

5. Ability to enable a "stick to floor" mode for transition between slopes. So - if you're running along a flat surface approaching a slope down, then you shouldn't go airborne as you transition onto the slope - unless the transition is greater than some authored angle.

 

Anyway - I hope some of these might be interesting things to think about if you haven't done them already.

 

Cheers - Danny




#5092931 PhysX - Scene scaling, object size, timestep and gravity inconsistency.

Posted by MrRowl on 10 September 2013 - 02:35 AM

physicsManager::update() {
float currentTime = clock();
   float deltaTime = (currentTime - mLastTime)/CLOCKS_PER_SEC;
   mAccumulator  += deltaTime;
   mLastTime = currentTime;

   while(mAccumulator > mStepSize) {
         mAccumulator -= mStepSize;
         mScene->simulate(mStepSize);
         mScene->fetchResults(true);
   }

}

 

OK - I see you changed this after first posting it to replace two calls to clock with one as I suggested. Can you confirm whether it does/doesn't work now?

 

There's still a potential problem that, according to the above code, you're probably storing your absolute time (mLastTime) as a float, as well as converting it to a float immediately after getting it. When the time gets large - which may not take very long since I expect CLOCKS_PER_SEC is pretty huge, then your deltaTime calculation subtracts two huge floats - and the result will get less and less precise. 




#5092821 PhysX - Scene scaling, object size, timestep and gravity inconsistency.

Posted by MrRowl on 09 September 2013 - 03:56 PM


about simulation numbers. ok, i spawned a unit sphere with a density of 1 at some height, and using PVD i measured that without any deltaTime scaling(so everything is slow-mo), gravity of -9.8f and stepSize of 1/30 it touched the ground in 2.5 seconds, falling 132 units from starting point. well, it's velocity wasn't constant, but i'm not sure how else can you measure it.

 

Do you mean that in 2.5 seconds (that is: 2.5 seconds of simulation time), your sphere, starting at rest, has fallen 132m? If so, that's much further than expected - you'd expect 0.5 * 9.81 * 2.5 * 2.5 which is about 30.7m. That would suggest your simulation is running faster than normal... so I'm not sure I've interpreted your numbers right.

 

In post 13 your loop multiplies by mStepSize, which is definitely wrong - but then you correct it in post 15. But it's still not quite clear what your latest version looks like.

 

In any case I'd expect this to work:

void update() {
        clock_t c = clock();
        float deltaTime = (c - mLastTime) / CLOCKS_PER_SEC;
        mAccumulator  += deltaTime;
        mLastTime = c;

        while(mAccumulator > mStepSize) {
            mAccumulator -= mStepSize;
            mScene->simulate(mStepSize);
            mScene->fetchResults(true);
        }
        // Ideally call something like sleepInSeconds(mAccumulator) here
}

I've replaced two calls to clock with one. I wonder - with your current code, assuming your scene is really simple, that update loop may spend a lot of time just spinning round, whilst it waits for the accumulator to accumulate, in which case each time it will lose a little bit of time - maybe that's where your slowdown is coming from?




#5092756 PhysX - Scene scaling, object size, timestep and gravity inconsistency.

Posted by MrRowl on 09 September 2013 - 11:06 AM

Physx...you might find yourself in trouble....there are not many(almost none) tutorials,or documentations for it

 

I don't quite understand what you mean - in my opinion/experience the documentation is extremely accurate, clear and complete. And the SDK comes with a bunch of samples, as well as tutorial/guides in the documentation. I'm not sure how anyone could ask for more, to be honest.

 

As for solving this problem - I'd recommend using the PhysX Visual Debugger - it's extremely useful generally, and only takes a couple of lines to set up the communication in your code. Then when you simulate, you can inspect pretty much everything, including the scene timestep, gravity, objects etc. If you're unsure whether things are moving as they should, set up a little test scenario in your game where you drop a sphere, and in the debugger check that it falls the correct distance in a given time period - distance = vel * time + 0.5 * gravity * time^2 

 

If you can't figure things out from that, you could even attach the pvd capture to a post here...




#5064083 Sloped Bullet Heightmap Inaccurate

Posted by MrRowl on 23 May 2013 - 02:41 AM

@MrRowl - nice trick! The btHeightfieldTerrainShape is a concave shape though.

 

I'm not sure what you're getting at...

 

It is a concave shape, but still btConvexTriangleCallback ends up getting called. Making this change can improve the frame rate of my app from around 15 to 25 FPS on lower-end mobile devices.




#5063064 Sloped Bullet Heightmap Inaccurate

Posted by MrRowl on 19 May 2013 - 02:16 PM

Using 2.81 version. It seems to be fast enough for my purposes (about a hundred objects falling on it at once as a demonstration/proof-of-concept). I'll keep that in mind though. Maybe commit your extra test upstream?

 

I just moved to 2.81, and noticed that there's still the same problem. Here's the modification that does the early out (it makes a really significant difference in my app - which is running on mobile devices so I need to get all the performance I can):

 

EDIT: Obviously this tweak is customised for my application which has z-up!

 

 
void btConvexTriangleCallback::processTriangle(btVector3* triangle,int partId, int triangleIndex)

{

  const btCollisionObject* ob = const_cast<btCollisionObject*>(m_triBodyWrap->getCollisionObject());
  //aabb filter NOT is already applied!
  // Quick check on AABB

  const btTransform& tr = ob->getWorldTransform();

  if (

    triangle[0].getZ() < m_aabbMin.getZ() &&

    triangle[1].getZ() < m_aabbMin.getZ() &&

    triangle[2].getZ() < m_aabbMin.getZ()

    )

  {

    return;

  }
 

 

In addition there are some redundant calls to getVertex in btHeightfieldTerrainShape::processAllTriangles, which I've removed, but which will be insignificant!
 




#5013095 shadow on plane

Posted by MrRowl on 21 December 2012 - 06:09 AM

Look up texture projection. You should be able to create a projection matrix (based on the light source and the sphere positions) that, when applied to the world space position of each vertex of the surface you're projecting onto, generates a texture coordinate for that vertex.


#5004465 PhysX Documentation

Posted by MrRowl on 27 November 2012 - 03:52 AM

I've seen that before: There's something on Windows where the first time you open a chm doc Windows warns you about some security stuff (or something like that). You click the button to say it's OK, and don't bug me again, but when the chm opens it doesn't show anything. However, open the chm again and all is OK...


#4998076 Sphere acting like a ball in Bullet Physics

Posted by MrRowl on 06 November 2012 - 10:10 AM

It will only roll if it has friction.

Similarly it will only bounce if it has a non-zero restitution.

You can set these things in rbInfo. You'll also need to set them on the environment objects as well, because the resulting behaviour is determined by the combination of restitution & friction. Probably Bullet calculates them by multiplying the properties of the two interaction objects - so for starters, make restitution and friction = 1 on everything, and then modify it until you get the behaviour you want.


#4996185 Compiled vs Scripted Physics Calculations

Posted by MrRowl on 01 November 2012 - 08:14 AM

I'd echo what Doug wrote.

My inclination is (based on experience) - scripted languages are useful when you need to ship an application whose behaviour must be modifiable by the user (beyond just being data driven). However, in every other area, they offer only marginal benefit at best given tools available with compiled languages (C/C++) - dlls, variable modification in the debugger, edit & continue. E&C in particular is incredibly useful (having worked on physics engines, AI and more).

On another topic - I would strongly advise against trying to use verlet integration and particles for 3D rigid body physics. In my experience, it ends up being much more complicated than impulse based methods (for which there's plenty of reference/info), slower and less well behaved. It seems way easier at first - but refining it involves hacks layered upon hacks... (I have some info, admittedly old now, that might be useful here)


#4961250 Braid algorithm

Posted by MrRowl on 20 July 2012 - 03:46 AM

Right? Where a is a constant value to give the braid some dimension.


Yes.


#4961088 Braid algorithm

Posted by MrRowl on 19 July 2012 - 04:27 PM

Sorry about that - I guess it was a dynamically created image. I've edited the post now.




PARTNERS