Hi there. We're working on integrating PhysX with OpenSG as well. Sorry if some of this has already been covered...
1) We are currently converting the coordinate system of PhysX objects at load-time and setting up the PhysX sim to operate in OpenSG's coordinate system. We may modify the exporter for 3D Studio Max so that it can do this conversion for us at export, but the current solution is working well so far. The "quick start integration guide" has a thorough example of converting from one coordinate system to another when using NxStream. 2) PhysX specifies it's primitives from their center point in halves. So, if you want a 1m cube, you would specify the distance from the center of the box. Think like you're defining the radius of a sphere. It's a little annoying, especially when defining the height of a capsule since it grows from the center, but at least it's consistent. When creating objects via code, we just take the values specified by the user (1m) and halve them for Ageia. Hope this helps some. Cheers E. --- Eric Maslowski Research Computer Specialist University of Michigan 3D Lab Autodesk 3D Studio Max Certified Trainer email: [EMAIL PROTECTED] office: 734-615-9699 mobile: 734-730-9904 -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Philipp Roßberger Sent: Friday, June 01, 2007 08:09 To: [email protected] Subject: Re: [Opensg-users] Ageia PhysX integration Am 01.06.2007, 13:31 Uhr, schrieb Marcus Lindblom <[EMAIL PROTECTED]>: > Philipp Roßberger wrote: >> Am 30.05.2007, 14:12 Uhr, schrieb Marcus Lindblom <[EMAIL PROTECTED]>: >> >> >>> Philipp Roßberger wrote: >>> >>>> 1) Coordinate system differences >>>> >>>> OpenSG and PhysX coordinate systems' use different axis orientations. >>>> While the coordinate system in OpenSG looks like this >>>> >>>> z >>>> ^ y >>>> | ^ >>>> | / >>>> -----> x >>>> >>>> >>>> the coordinate system in PhysX looks like this: >>>> >>>> y >>>> ^ z >>>> | ^ >>>> | / >>>> x <----- >>>> >>> Both are righthand system. Does this PhysX care about the "front" of an >>> object? (OpenSG does for the camera & lights, but little else, I think) >>> >> So far I didn't find anything in PhysX where an object front is defined. >> > Ok. Maybe it's up or right? Or if PhysX doesn't care about that, what is > the actual problem? > > What I'm getting at, is, that you might be able to use OpenSG > coordinates within PhysX? (i.e. just set the gravity to be in -z). I got no problem at this point. I just wrote about the differences in hope that other people trying the same will recognize the difference earlier than I did ;-) >>> In any case, it's not hard to transform back-and-forth between these, >>> is >>> it? >>> >> Not really. Here a short example, that shows how I use values computed >> by >> the PhysX engine to transform OpenSG objects: >> >> //PhysX part >> NxVec3 pointerPos = pointer->getGlobalPosition(); >> NxQuat pointerRot = pointer->getGlobalOrientationQuat(); >> >> //OpenSG part >> mPointer.setTranslate(-pointerPos.x, pointerPos.z, pointerPos.y); >> mPointer.setTransform(Vec3f(-pointerPos.x, pointerPos.z, pointerPos.y), >> Quaternion(Vec3f (-pointerRot.x, pointerRot.z, pointerRot.y), >> pointerRot.w)); >> > Either that, or you could define a matrix which rotates from one system > to the other: > > static OSG::Matrix msPhysXtoOpenSGmtx(...); > > mPointer.setTransform(PointerPos, Quaternion(PointerRot)); > mPointer.mult(msPhysXtoOpenSGmtx); // or multLeft() perhaps > > It's a basis change matrix, so either build it from two rotation > matrices (it looks like it could be done that way) or set the bases > directly. I.e. set each of the first three columns to each x,y,z vector > of the other coordinate system, or vice versa (I can never remember > which way it goes. :) > > It's a bit tricky, but you should be able to get it done. Understanding > transformation matrices well will make your life a lot easier, so read > up on it if you feel you need it. (I don't know enough either, as you > can see.) Well I think I have to dig deeper into this topic. You are right, it's much easier to do all this stuff, when you know what you are actually doing. >>>> 2) Object scaling >>>> >>>> Objects instantiated in PhysX with default scaling are twice the size >>>> as >>>> their OpenSG counterparts. Here an example: >>>> >>>> Box in OpenSG | Box in PhysX >>>> ----------------------------- >>>> 1,1,1 = 0.5,0.5,0.5 >>>> >>>> >>> Yup. Primitives in OpenSG are unit sized, they do not have unit-coords. >>> I don't know which is better actually. :) >>> >> PhysX parameters are set up by default assuming 1 unit = 1 meter. I am >> wondering what would be the best way to make sure, that scaling in >> OpenSG >> and PhysX is equal. I was thinking about experimenting with the raycast >> methods in OpenSG and PhysX. Any better ideas? >> > Right. However, OpenSG doens't care about units. So if you want one unit > to be one meter, that's perfectly ok. (You could have an OpenSG unit be > one furlong as well, but that's just weird :-) > > I think this problem is just a mismatch between the vertex values of > each library's box-primitives. Without knowing what you are doing in > detail, these are some ideas: > > * Make your own boxes in OpenSG, with correct values. (might be simpler > & probably faster, if you can do this) > * Export the OpenSG box to PhysX, as a generic mesh. (avoids any such > problem, but generic meshes might be slower in PhysX) I will go with solution 1) and scale the boxes in OpenSG with correct values. I just managed to get the raycast reports working in PhysX and now make some tests to determine the acutal scaling differences by comparing the raycast values of OpenSG and PhysX. Solution 2) looks a little bit scary to me ;-) >> By the way: is there a method in OpenSG that allows you to convert world >> coordinates into the local coordinate system of an OpenSG body? I need >> this to create joints between objects. The anchor points of certain >> joints >> in PhysX are defined in the local coordinate system of individual >> bodies. >> > Yes. The inverse of the toWorld() transform will do that, i.e: > > OSG::Matrix fromWorld; > node->getToWorld().inverse(fromWorld); > > Pnt3f localCoord = fromWorld.mult(worldCoord); > Cool, that's just what I needed. Thanks for your help and your ideas Marcus! > Cheers > /Marcus > > ------------------------------------------------------------------------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > Opensg-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/opensg-users -- http://www.placemarks.net ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Opensg-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/opensg-users ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Opensg-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/opensg-users
