PNS_PhysX [The only physX wrapper 4 linux] (QUAD/HEXO core)

[devsh]

NOTICE TO ALL
I would appreciate if you could post a list of things this wrapper should be able to do apart from removing, creating boxes and spheres.

EXPLOSION


NOTE: MOTION BLuR is ON!!!


ORIGINAL POST

getting ready for the intel i9 and using the opportunity of physics simulation with many cpu cores...
3 for quad cores + 1 helper thread + irrlicht thread
5 for hexocore

Code: Select all

   //sceneDesc.flags |= NX_SF_SIMULATE_SEPARATE_THREAD; //I'm gonna make your quad core scream for mercy
   sceneDesc.flags |= NX_SF_ENABLE_MULTITHREAD;
   sceneDesc.backgroundThreadCount = 1;
#ifdef INTELi9
   sceneDesc.internalThreadCount = 5;
#else
   sceneDesc.internalThreadCount = number_of_threads;
#endif

UNTILL THIS WRAPPER GET MORE FUNCTIONAL THAN IRRPHYSX, THERE IS NO SUPPORT FOR NODES WITH PARENTS

i'm going to make a sudo wrapper, with some helper classes for specific nodes.

this will be to help to start people off with physX like me!

there will be a class for force fields (explosions, tornadoes etc.), rigid bodies, dynamic meshes (characters), softbodies (cloth), and "jetstreams" (water, bullets etc.) that will cause particles to form at the point of collision (sparks, water spray) AND paged meshes for large stuff.

The reason I call this a sudo wrapper:

-You can have direct access to physX core via pointers that you can get from my daddy class
-You can work the insides of physX directly because the main include file for your project will include physX libs and headers
-This is because someone told me that wrappers kill flexibility

P.S. any model donations would be good.

[devsh]

There is a reason for reinventing the wheel

most people should see a rather big framerate drop on dual cores...

this is why:

NxScene* gScene;
NxReal myTimestep = 1.0f/60.0f;
...

void mySimulationStepFunction()
{

gScene->simulate(myTimestep);
gScene->flushStream();

//...perform useful work here using previous frame's state data

gScene->fetchResults(NX_RIGID_BODY_FINISHED, true);
}

There are several variations to the fetchResults() function call, selectable by the parameters of the function, or by using the function checkResults() in its place. The version illustrated above is a blocking function: the function will not return until the simulation thread has completed its calculations on all rigid bodies (i.e., NX_RIGID_BODY_FISHED == true).

irrPhysX does exactly that in its fetch() function, it will not return untill physics calculation is complete:

my syntax is as follows:

Code: Select all

//declare your game function -- as opposed to game loop

void render(UserData UD) {
   ...render ur stuff...
}

// UserData will be an abstract data type which will be declared by you to include all your data... i.e. smgr pointer, device, etc. , special nodes like water

physX_PNS->setGameFunctionLoop(&render, UD);

// the body of the fetch function
    void fetch(float Timestep)
    {
        gScene->simulate(myTimestep);
        gScene->flushStream();

        //...perform useful work here using previous frame's state data

        while(!gScene->fetchResults(NX_RIGID_BODY_FINISHED, false)
        { 
            GameFunctionLoop(userData);
        }

    }

[devsh]

PROGRESS REPORT

the lib has grown to 18kb now

and i ran a test with async stepping, and the function pointer methdo works nicely.

Also I will be making some functions to finally place objects in the world!!! i.e. boxes

Please advise me if this API reference is understandable:

/*====================API REFERENCE=======================================
PNS_PhysX by devsh, matthew kielan

HOW TO:

1) declare an instance of physX_PNS

2) instead of making a game loop in your game... make a game function
that will/can be executed in the game loop

NOTE IMPORTANT: The ONLY argument it can take in is UserData,
the UserData class will provide you with the
pointers to driver, device etc.
NOTE IMPORTANT: The FUNCTION MUST BE VOID!!!
NOTE IMPORTANT: NEVER ADD PHYSICS OBJECTS IN THE GAME FUNCTION

2) declare a UserData instance and pass the device pointer in it's constructor

a) if you need any other pointers and/or special objects/nodes to be
passed on to the function, derive your own class from UserData and
then type cast it inside the game function
NOTE: For variables already available in UserData look in the USERDATA
section.

3) use physX_PNS member function called
setGameRenderLoop(void (*gameRenderLoop)()) and pass a pointer to
your game function

4) then in your game loop, call the member function physX_PNS::simulate(UserData)
and feed it with your UserData, you do not need to call your game function
because the physX_PNS::simulate(UserData) member function does it for you
using the pointer.
NOTE: calling your game function after or before physX_PNS::simulate() will
not distabilize the game, but may lead to slowdowns. But more likely
the physics simulations might be choppy.




USERDATA:
There are common pointers to stuff that you will most likely need
in your game loop, They are all public members of the UserData class.
These are their definitions:

THESE ARE AUTOMATICALLY SET WITH THE UserData CONSTURCTOR
irr::IrrlichtDevice* device;
irr::gui::ICursorControl* CursorControl;
irr::io::IFileSystem* FileSystem;
irr::gui::IGUIEnvironment* guienv;
irr::ILogger* Logger;
irr::IOSOperator* OSOp;
irr::scene::ISceneManager* smgr;
irr::ITimer* Timer;
irr::video::IVideoDriver* driver;

THESE YOU CAN MANIPULATE
irr::core::array<irr::scene::ISceneNode*> nodes;
irr::core::array<irr::video::ITexture*> textures;



ADVANCED:

If you know the nVidia PhysX API and would like more flexibility,
or even work as if the API is not there...
There are pointers to stuff needed for direct PhysX interaction.
The way PNS_PhysX is designed:

--->|PNS |-->
game -------------> Nvidia PhysX
--->|PhysX|-->

so you still have direct acess channel, the PhysX main include file is put
in the PNS_PhysX header that you put in your game. You can use all the
classes and types that nvidia uses.

Here are the global variables and pointers that PNS_PhysX provides you with
for full acess to PhysX:

-pointer to the physX engine NxPhysicsSDK = through physX_PNS::getPhysXSDK()
-the scene descriptor NxSceneDesc = through physX_PNS::getSceneDescriptor()
-pointer to the scene NxScene = through physX_PNS::getScene()
=========================================================================*/

[BlindSide]

May I suggest following the Irrlicht model and using inheritance to provide callbacks instead of function pointers? It lets the users keep all the data in the same class where the function resides so you wouldn't even need to pass user data.

If you're not totally sure what I mean, I mean provide an IGameLoop interface with a "virtual void update() = 0" virtual update method which the user gives the pointer to. Just like Irrlicht does with IEventReceiver or ISceneNodeAnimator.

Cheers

[devsh]

yeah i might as well... anyway i think i should get the first cube demo started
The biggest problem here is just updating scene node rotation and translation,
and having everything in sync.

Would it make sense to have a separate thread for updating node transformations, or is it too dangerous with threading. Also if its even worth threading since there is not much work included in updating matrices.

P.S. its good that we got asynchronous stepping out of the way

[P1SQ4M]

Hurray for helpful physxs!

[devsh]

this thing is designed to do things irrPhysX sucks at

UPDATE:

as I said this is a sudo wrapper.... it can be used in ways that allow you maximum control

5)
5a)To add a physics to a node, use the member function
physX_PNS::makePhysXForSceneNode(irr::scene::ISceneNode* node,
float density_kgm3,
irr::core::vector3df linear_vel=irr::core::vector3df(0,0,0),
irr::core::vector3df angular_vel=irr::core::vector3df(0,0,0),
float angular_damping=0.05, float linear_damping=0.f)
The physX wrapper will dynamically detect the kind of node, ie. mesh, cube, sphere
and will cook it or make a simple actor for it. Cooking means to convert a mesh
into a simple "mesh" made up of boxes for physics simulations.
You also need to specify the density of the node, ie.
- Water has a density of 1000 kg/m³ so you would enter 1000 kg as density_kgm3
- 1010 kg/m³ = average human body
- 10490 kg/m³ = silver
- 11340 kg/m³ = lead
- 2000-8000 glass
- 50-100 for a wooden crate
- 8940 for copper
- 7850 steel
- 1750-2400 for concrete
- 1760-2560 limestone
- 1922-2563 for bricks
- Cardboard 689
- 129-2165 cement
- 2691 Granite
Earth, loam, dry, excavated 1249
Earth, moist, excavated 1442
Earth, wet, excavated 1602
Earth, dense 2002
Earth, soft loose mud 1730
Earth, packed 1522
Earth, Fullers, raw 673
MOST woods will float (save for ebony) http://www.simetric.co.uk/si_wood.htm
YOU CAN GOOGLE THE REST

5b) If you are more advanced in the fields of physX you can make an actor (PhysX term) for your node
with a custom body descriptor, the function is:

NxActor* makePhysXForSceneNodeWithCustomDesc(irr::scene::ISceneNode* node, NxBodyDesc bodyDesc);

6) both of the functions have their shorter versions, and they take in the same parameters:

makePhysXForSceneNodeWithCustomDesc = mPFSNWCD
makePhysXForSceneNode = mPFSN

[Seven]

one item that i recommend is that you allow for multiple physics worlds to be loaded at the same time and then able to switch between them. When designing your wrapper, please dont assume that there is only one physics world. this way, you can load a physics capable menu system and a physics capable game world, and then switch back and forth from menu to game world easily.

[devsh]

this is not a complete solution...

if you want multiple physics worlds...

a) call another class of physx_PNS
b) do it yourself

[devsh]

its soo sweet (i think its more the SSAO than the boxes flying)

[devsh]

should I make a function to do anisotropic friction, or since the user has all the variables, pointers and includes (and also knows something about physics middlewares to know the term anisotropic friction) should the user just use the setActorMaterialWithCustomDescriptor(actor,desc)???

[Virion]

this thing is designed to do things irrPhysX sucks at

maybe you should improve irrPhysx instead of making another different wrapper? just my 2 cents.

[devsh]

i dont like the way irrphysX is made

[wildrj]

Devsh maybe you could elaborate on why you dont like irrPhysx rather then just say it?

[Halifax]

this thing is designed to do things irrPhysX sucks at

maybe you should improve irrPhysx instead of making another different wrapper? just my 2 cents.

QFT

You are just reinventing the wheel when you could just improve the wheel. If you don't like something about IrrPhysX, talk to JP then-- in a sensible way mind you. You have a knack for coming across very cycnical e.g. "this thing is designed to do things irrPhysX sucks at."

At any rate, good ideas, but poor execution.