Jump to content

  • Log In with Google      Sign In   
  • Create Account


fanwars

Member Since 27 May 2010
Offline Last Active Private
-----

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

Posted by fanwars on 05 March 2014 - 03:47 AM

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




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

Posted by fanwars on 03 March 2014 - 12:39 PM

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




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

Posted by fanwars on 03 March 2014 - 08:09 AM

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?



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

Posted by fanwars on 03 March 2014 - 02:39 AM

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.




#5135816 [PhysX] Move controller + getting its velocity

Posted by fanwars on 02 March 2014 - 02:44 AM

Internally the controller framework uses setKinematicTarget() so one can only guess what PhysX does beyond that point. I don't know if it's even valid to use getLinearVelocity with kinematic actors...

 

However, since the displacement is accurate, why not use it to calculate the velocity yourself? Just keep the previous and current position between updates and divide the displacement with your timestep.




#5135623 [PhysX] Move controller + getting its velocity

Posted by fanwars on 01 March 2014 - 06:17 AM

You can't rely on the actor's velocity in this case... The character controller framework does so much more under the hood. You should track the velocity manually. Using that "dir" in your code should be perfectly fine (e: unless the controller touches something - you have to check for these conditions).

 

One way to handle the gravity is to manually apply the acceleration. The cc framework provides the raycast result flags. If the bottom of the cc touches ground (or something else), just reset the velocity's z-component or modify it according to conservation laws. The up direction is used to do these raycasts and to determine the orientation of the cc shape.




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

Posted by fanwars on 05 September 2013 - 01:17 PM

I guess the ultimate point of these snippets is to keep the physics timestep fixed while graphics run at higher fps interpolating frame results. There are obviously
better solutions than this piece of code and those will be more relevant at later development stages... Since your graphics run at constant 30fps, you could perhaps replace that code with just simulate(1.0f/30.0f) and fetchResults(true) and keep looking until you find the actual problem. fetchResults can be called right after simulate as long as that first parameter remains true. I suppose it's also possible to "hack" some speed by making that dt > 1/30 (or even better call twice those functions), did you try the direct approach?



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

Posted by fanwars on 05 September 2013 - 09:52 AM

If you're sure that slowness isn't just an illusion caused by big objects (after all, even a unit sphere can seem to accelerate pretty slow from distance in empty world) it's most likely a bug in timestepping or anything related. Like I'm not sure if that "mLastTime = clock();" should be there after "return" -> deltaTime grows too big if mAccumulator < mStepSize (mLastTime should be updated in any case). But slo-mo is usually pretty easy to fix if the simulation is otherwise working correctly.




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

Posted by fanwars on 05 September 2013 - 05:56 AM

Hm ok, so that's not the problem then. I recall that scale thing being a source of some problems earlier, but don't know about that anymore. I'm using 3.3 beta 2 myself now.

 

Initialization seems ok. Check filter shaders and possibly compare your code to those (awful) examples in case you're missing something. Are you calling PxRigidBodyExt::setMassAndUpdateInertia for dynamic actors after creating all the shapes? That's also pretty important. You shouldn't need that setMass() at all.

 

I'll post if something comes to mind while coding my own stuff.




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

Posted by fanwars on 05 September 2013 - 04:17 AM

That PxMeshScale is probably what you should attempt to get rid of, for now. Scale should be 1.0, and the actor size determined entirely by the convex hull dimensions (at the point where you "cook" it). How big is the convex hull anyway, I mean the approximate distance between two furthest points forming it?
 
At least in earlier versions of physx 3.x, that PxMeshScale didn't fix oversized convex hulls. Did you already try unit spheres (for example), to see if they make any difference in speed? And how's your initialization code?



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

Posted by fanwars on 05 September 2013 - 02:30 AM

Well, first I'd try leaving all the weird scaling factors untouched and decide exactly the measures of my world. Start with 1 unit = 1m and begin experimenting with some convex hulls no larger than 5 units (unscaled). Too large objects can be deceiving as they may seem to fall in slo-mo. After these "standard sized" actors are behaving correctly, you can start putting more arbitrary actors in. And if physx provides any scaling factors I strongly suggest ignoring them as they can initially cause problems exactly like these.




#4970144 Unable to find interface in namespace

Posted by fanwars on 16 August 2012 - 07:01 AM

It seems like methods GetInterfaceCount() and GetInterface() are ignoring namespaced interfaces. For example:
psg->SetDefaultNamespace("Base::Control");
psg->RegisterInterface("IComponent");
psg->SetDefaultNamespace("");

//Code pretty much the same code as in the angelscript's game sample
asIObjectType *pt = 0;
bool f = false;
uint otc = pm->GetObjectTypeCount();
for(uint i = 0; i < otc; ++i){
  pt = pm->GetObjectTypeByIndex(i);
  uint ic = pt->GetInterfaceCount();
  for(uint j = 0; j < ic; ++j)
   if(strcmp(pt->GetInterface(j)->GetName(),pintfn) == 0){
	f = true;
	break;
   }
}
if(!f)
  return false;
//...


class SpectatorControl : Base::Control::IComponent{
SpectatorControl(Actor @t){
  @a = t;
}
//...
Actor @a;
};
Probably not a feature? Or am I failing it again..?
I also tried nesting these methods in SetDefaultNamespace(), but it didn't make any difference.
Without namespaces the method above works correctly.


#4945653 Your first game idea - What happened to it?

Posted by fanwars on 02 June 2012 - 02:38 PM

I was much into early GTA-style open world games, and I thought it'd be cool to create something similar myself. After having been learning c++ for a short period and some basic game -related things such as main loop I created a few prototypes of the game using console graphics.

Here's a screenshot of the final version:
con_.png
An intense firefight in some hotel hall. The map scrolled as the player moved around.

Pretty much everything was hardcoded (enemies, weapons and objects), except the maps which also supported primitive events (walk somewhere and something is spawned). The game had cops, civilians, enemy gangs and even some monsters. Available weapons were two types of shotguns, rocket launcher, flamethrower, mines, remote detonated bombs and my personal favorite - poison arrows Posted Image .

The game featured some pretty cool blast wave, fire and blood splatter effects - all done using colorful ascii characters. Among console graphics and 2d game stuff I also learned something about AI and sound system (the game btw had extremely brutal death screams). Later I tried adding a multiplayer, but of course that would fail as I had zero knowledge on the subject and I was using tcp for everything!

If I did a remake of this thing with my current experience and knowledge, it would probably end up being insane. I've actually started to recreate this thing in 3d, and so far everything's been going great! I might post an iotd some day, so stay tuned Posted Image !


#4898085 Assimp & Normal Maps

Posted by fanwars on 30 December 2011 - 02:20 AM

Did you try opencollada exporter? It works pretty well for skinned and animated stuff. You may have to let assimp recompute the normals or tangents for some meshes, though.
And if you're using CAT or other such tools, the best results are achieved when you first export to FBX, then import it back and finally export with opencollada Posted Image .

Collada for skinned meshes, ASE for static/collision meshes, and the "quality" is guaranteed.

I was also thinking about writing my own 3ds max exporter. I actually tried, and I got my mind shattered. And I thought my future artist isn't going to use 3ds max anyway, so I impatiently quit... Sure is all the hassle with exporters, importers and manual tweaks waste of time, but now that I found at least somehow working asset exchange pipeline, I think I can handle the pain.


PARTNERS